Визуальный инструмент разработки под Android

В свое время читал об этом инструменте, но он был в закрытой бете.
Сейчас уже можно пользоваться: http://appinventor.googlelabs.com/about

Вебинар "Design Rules And Principles"

Презентация прошедшего вебинара.

Design Rules And Principles

View more presentations from Евгений Кривошеев.

Test-Driven Development (TDD) Workshop - как пощупать инженерную практику, чтобы не было больно на утро

Сегодня об инженерных практиках, которые активно используются в гибких (agile) методологиях (хотя эти практики свободно масштабируются на произвольные процессы) ходит много споров и обсуждений. В том числе и о TDD из процесса XP. 

При этом возникает ряд проблем внедрения этих практик. Их рассмотрение я оставлю out of scope. Но желание разработчиков пощупать, потестировать подход остается и даже возрастает (с каждой прочитанной книгой ;-). 

В свое время я разработал игру-симуляцию, которая позволила бы это сделать с базовым набором XP-практик: TDD, pair programming, iterative development и simple design. И после проведения серии этих воркшопов назрел целый ряд интересных выводов:

1. Игровая форма рулит.  Мы все читали и слышали, что игры - один из самых эффективных инструментов обучения. Но на практике это превосходит ожидания. 2 часа кодирования пролетают, по словам участников, как 30 минут. Даже для не-разработчиков (тестеров, pm-ов).
2. Воркшоп дает крайне эффективную обратную связь. Наблюдение за работающими над заданием участниками - ценнейший источник информации о них. А результаты выполнения задания говорят сами за себя.
3. Участники сами приходят к выводу о целесообразности используемой практики. Правильно выстроенный воркшоп заменяет килограмм лекций о необходимости, например, модульного тестирования.
4. Воркшоп снимает страх или лень использования практик. В игровой форме (когда нет контроля начальства сверху) участник может попробовать использовать практики, которые в проекте избегает из-за инерции или риска нарушения процесса.

Статистика проведения эвента показывает его высокую образовательную эффективность. Поэтому, собственно, message: Коллеги pm-ы, проектировщики и разработчики! Если Вы хотите внедрить в своем коллективе какую-либо инженерную практику практически без сопротивления, создайте собственную игру-симуляцию, учитывающую специфику коллектива. Эта игра создаст максимально комфортные условия знакомства с практикой и при правильной проработке этой игры подтолкнет коллег использовать практику.

Безусловно, возникнет ряд сугубо методических нюансов - как выстроить игру, максимально раскрывающую все грани практики. У меня, даже с учетом богатого опыта проведения обучения, получилось отточить все детали только после 3-4 проведений. Зато теперь этот воркшоп - крайне эффективный инструмент знакомства с практиками, выработки навыков и передачи знаний; игра стоила свеч ))

Если кто-то захочет использовать такой подход, но имеет методические трудности - пишите, буду рад помочь. Хотя, крайне часто хорошие специалисты так же нагружаются образовательной активностью для junior-коллег, так что создание такого обучающего проекта их не введет в ступор ))) Надеюсь, мой message об эффективности таких подходов будет услышан )

Успехов!

Судьба девелопера: куда податься дальше?

Недавно с одним товарищем полемизировали на эту тему. Действительно, многие ребята всерьез озадачены вопросом дальнейшего роста. Куда двигаться? Любое движение, за редким исключением (когда это пинок ;-) - результат продуманной политики, и главное в этом движении - внятно сформулированная цель.
Какие пути развития видятся experienced-разработчикам? На основе моей репрезентативной выборки (знакомые) можно отметить следующие варианты развития:

• в техническую сторону - гуру/архитектор/lead
• в сторону управления - project manager
• в сторону консалтинга - преподаватель/инструктор/пре-сейл (pre-sale)
  
• "между право и лево выбираем вверх" - собственное дело

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

Хороший технический специалист: гуру/архитектор/lead.
Что ждет? Высококвалифицированные спецы всегда нужны. Особенно это ощущается сейчас, когда хедхантеры готовы на многое, чтобы найти таких людей. Что поделать - кадровый голод )))
В перспективе гуру ждет участие в сложных проектах на уровне технического архитектора, и чем выше квалификация, тем сложнее и масштабнее проекты. В идеальном будущем - позиция вида "главный дядька по архитектуре решений" в какой-нибудь мега-крупной конторе ))
В реальности же все гораздо более прозаично и совсем немного ребят доходят до таких позиций, именно технических, чаще всего сворачивают. Основная проблема - финансовые амбиции. Обидно, когда ты такой умный, а за стенкой сидит паренек, который (страшно сказать!!!) не знает, что такое SAML для веб-сервисов, и получает больше тебя... А паренек занимается не технической стороной дела, а организационной - он PM. Или директор по развитию бизнеса. Или сами-посмотрите-на- табличку-на-двери-того- самого-упыря-достал-уже )))
Потому многие (амбициозные особенно) сворачивают в сторону управления.
Что необходимо? Если у Вас есть абсолютно четкое понимание:

1. Того, что Вам нравится именно технологическая сторона, что Вы - технарь (в самом лучшем и гордом смысле этого слова, а не какое-то там офисное чмо ;-)
2. Того, что Ваша компания позволит Вам расти в этом направлении. (Или Вас зовут в компанию, где в этом плане все будет хорошо ;-)

надо планомерно прокачивать скиллы.
Здесь так же есть пара нюансов. Можно стать отличным специалистом широкого профиля - эдаким техническим архитектором по платформе или по решениям. Например, по "платформе J2EE" или по "портальным решениям". С другой стороны, можно стать гуру по определенному продукту - например, по конкретной софтине BEA WebLogic 9.2.
Оба подхода, конечно, крайности - сложно быть спецом по платформе, не имея опыта на конкретном сервере и, наоборот - быть специалистом по конкретному серверу, не имея представления о платформе. Но задуматься о направлении, о доминанте, конечно, стоит. Эти спецы по-разному востребованы работодателями.
И еще одна важная деталь - сертификация. Сертифицироваться надо, это очень сильно облегчит общение как с текущим, так и с будущим работодателем )
Кому подойдет? Настоящим технарям, любящим свое дело и сложные задачи, не потерявшим интерес к развитию скиллов. Но важно уметь оценивать свои амбиции и уметь сворачивать вовремя )

Управляющий процессами разработки - Project Manager/Program Manager.
Что ждет? PM-ы - достаточно востребованные люди, hh.ru подтвердит ) Из несомненных плюсов - то, что они могут отностительно свободно сменить предметную область без смены скиллов. Это позволит начать карьеру PM в конторе "на-троих.ру", и в будущем оказаться в компании "Мега-Корп.ком".
Конечно же, все очень сильно зависит текущей ситуации: и проект может оказаться провальным, и все что угодно. И компенсация у PM зачастую скромная, тот же hh.ru подтвердит. Но, в целом, направление развития достаточно перспективное.
Отдельно стоит упомянуть сертификацию - она достаточно сложная и длительная по сравнению с техническими сертификациями. Но прохождение её, на мой взгляд, крайне полезно.
Что необходимо? Умение соображать быстро и верно ) Умение управлять людьми и общаться с ними. Деловая хватка.
Умение ждать ) Вовсе не следует ожидать сразу огромных компенсаций.
Кому подойдет? Эти умения и навыки приходят с опытом, но, тем не менее, некоторая предрасположенность к такого рода деятельности должна быть изначально. Далеко не все имеют способности к грамотному управлению людьми, деловому общению и способности к принятию решений.

Несущий свет - консультант/преподаватель/инструктор/пре-сейл )
Что ждет? Инструкторы и преподаватели - не такая частая вакансия на сайтах кадровых агенств, но это отнюдь не значит, что это бесперспективняк )
Я не имею в виду институтских преподов. Это люди, работающие в учебных центрах (как самостоятельных, так и подразделениях материнских компаний) и не имеющие ничего общего с большинством тех самых институтских преподов )
Задача инструктора - внятно донести содержание курса. Курсы по IT-направлениям, как правило стандартные, то есть уже написанные. И инструктор, пользуясь этими материалами, ведет группу на протяжении всего курса, "читает" курс. Длительность курсов различна - от одного до пяти полных (восьмичасовых) дней, иногда - дольше.
Из минусов работы инструктором можно отметить:

• Высокая физическая нагрузка. Внятно, четко и громко говорить пять восьмичасовых дней - далеко не каждый сдюжит.
• Высокая эмоциональная нагрузка. Группы бывают ой какие разные )))
• Высокие требования к инструктору: умение внятно объяснять плюс отличная техническая подготовка. И если со вторым не так все плохо, то с первым - беда, таких людей совсем немного.
• Если УЦ проводит неграмотную кадровую политику, не давая развиваться инструктору, то рано или поздно ему надоест читать одни и те же курсы.
  

Из плюсов же можно отметить:

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

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

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

Кому подойдет? Всем тем, кто гармонично сочетает в себе технаря и оратора )))

Собственное дело
Как ни удивительно, но достаточно много ребят задумывались или задумываются о каком-либо своем начинании. В силу специфики их текущей работы, это как правило, мысли об e-business. Я это связываю с наличием удивительных success stories, тех же Google или YouTube.
Тема эта очень серьезная и требует отдельного размышления. Так что постараюсь как нибудь их собрать и совместно выработать идеи и рекомендации. Возможно, попробуем написать совместную статью.

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

Отступления:

1. Статья не претендует на истину в последней инстанции. Она основывается на персональной репрезентативной выборке. Мнение читателя не обязано совпадать с мнением автора. Конструктивная полемика приветствуется.
2. В силу специфики блога (Java/J2EE) чаще всего имеется в виду работник, связанный именно с этим направлением.
   
3. Многие неглупые люди (например, М.Фаулер) обозначают определенный негатив к термину "архитектор" из-за его неоднозначности. Я с ними солидарен )) Выше я употреблял этот термин с уточнением "технический" и лишь потому, что этот термин потребовал бы слишком объемной и выходящей за рамки формата расшифровки.
4. "Между право или лево выбирает вверх" - © Гражданская Оборона.
   

Проектирование ПО мертво?

Все тот же омский коллега порекомендовал статью гуру Мартина Фаулера.
Ссылка на русский перевод: http://www.maxkir.com/sd/designDead_RUS.html

Культурологические аспекты разработки ПО на заказ )

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