Россия далеко не на первом месте в мире, но первая по количеству исследований в своем макрорегионе

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

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

Шаблоны проектирования Cucumber BDD сценариев

Цели:

• получить готовый инструмент, при помощи которого станет возможным стандартизировать процессы разработки и контроля качества исполняемых сценариев, построенных для работы в Cucumber-based технологических стеках (cucubmer jvm, SpecFlow и проч.)
• получить набор правил, позволяющих специалистам с разных проектов легко мигрировать между проектами без длительной фазы привыкания
• получить чистый, легко-читаемый код сценариев, который легко расширяется и слабо подвержен полным переписываниям текстов сценариев при минимальных изменениях UI

Итак, поехали!

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

А как делать этот самый рефакторинг, если даже неизвестно, с чего начать? Как осушить болото кода и не утонуть нем?

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

Google Gears — открытое программное обеспечение от Google (бета, лицензия BSD), позволяющее использование веб-приложений с помощью браузеров Mozilla Firefox и Internet Explorer под GNU/Linux, Mac OS и Microsoft Windows в режиме оффлайн.

Специальный плагин заставляет браузер работать с локальным кешем страниц (на основе SQLite), периодически синхронизируя кеш с онлайн источником.

Google gears представляет собой AJAX-API и работает только с веб-сайтами, специально поддерживающими этот сервис. (Источник)

Так вот, почитав немного документацию, я решил интегрировать такую вещь в один сайт. Итак начнем.

«Цель: получить работу в IBM»
— пишет какой-то идиот-соискатель в Amazon.com.

---

ВНИМАНИЕ: это мое собственное, *персональное*, мнение, не Google, не Amazon или кого-либо еще. Я думаю вы обнаружите, что большинство рекрутеров, оценивающих анкеты в технических компаниях — особенно в технических компаниях, которые производят собственное программное обеспечение сами, такие как Yahoo!, Ebay, Amazon.com, Microsoft или Google — в целом, согласятся со многим из перечисленного. Но опытные рекрутеры расходятся во мнениях касательно многих мелких деталей, и, в конце-концов, это всего лишь мое собственное мнение. Эти советы не гарантируют получения Вами сколь-нибудь лучших результатов. Возможно, у вас будет другой опыт. Не используйте эти советы в ванной или стоя в луже. Не стучите по стеклу, это раздражает советы. Советы не кормить! И т.д.

---

Про то, что от программизма портится зрение — знают и говорят почти все, но мало кто задумывается о не менее важной части тела — спине.

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

В данном посте затронул ключевые моменты и ошибки в вопросах

1. Как мы сидим
2. На чем сидим
3. Зарядка
4. Спорт

Читая хабратопик «Работа и успех (?)», вспомнил одну поучительную то ли байку, то ли притчу, называйте как хотите, рассказанную мне руководителем накануне защиты диплома в институте.

Навеяно комментариями к топику Как найти подходящее имя для стартапа Сначала я хотел написать развернутый комментарий, потом — гневный топик, клеймящий позором всех, кто пытается «генерировать» идеи методом перебора, в то время, когда ТРИЗ существует с прошлого века.

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

Итак, нам нужно придумать имя для стартапа. Оно должно быть легко запоминающимся, желательно с нужным смыслом, желательно коротким и обязательно не занятым в плане домена.

При этом для большинства тем (особенно конкурентных) все возможные варианты давным давно перебраны и заняты.

Знакомая ситуация? А вот решение:

Многие, наверное, помнят игру Progress Quest — уникальную РПГ, не требующую внимания игрока и тем самым экономящую ему кучу времени, которую можно потратить с большей пользой. К сожалению, последние годы она никак не развивается, да и необходимость запуска локального клиента утомляет.

Позвольте представить вам Godville — вариацию на тему PQ, адаптированную под онлайн. Ничего, кроме браузера, не потребуется — единожды созданный герой будет неустанно совершать подвиги, смиренно ожидая вашего следующего визита к нему.

Часто встречал ситуации, когда люди не понимают целей презентаций. Например, на научной конференции (!) девушка в научный доклад вставляла анимацию для того чтобы «доклад не скучно было смотреть». Для меня это было дико.

Создавая презентации, или рецензируя чужие, я руководствовался собственными впечатлениями. Когда же наткнулся на документацию к LaTeX Beamer, был в восторге: там было не только подробное руководство по собственно латех-бимеру, но и общие рекомендации по созданию слайдов. Читая документацию я буквально радовался каждому абзацу, ловя себя на мысли «Да, да. Точно, правильно.»

И когда возникла необходимость составить рекомендации по созданию презентаций для конференции RuPyRu, я вспомнил про документацию к бимеру. Она и послужила основой для общих рекомендаций. А уже на основе общих рекомендаций я составил упрощенную редакцию, которую и привожу здесь:

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

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

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

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

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

По просьбе товарища keksn, администратора блога Mobile Development, сливаю прошлые посты-ссылки о разработке для Palm WebOS в один пост.

Добрый день, друзья, хочу поведать вам один секрет, который помогает мне быстро и правильно найти цветовую схему для сайта.Прошу строго не судить, возможно, некоторые из вас знают этот прием, но вот мой друг, не знал, а когда я поведал ему, как легко найти цвета для цветовой схемы сайта – он был поражен простотой решения. Я не претендую на уникальность, либо открытие нового метода, просто я это знаю, и мне это помогает.
Для того чтобы нам создать цветовую схему. Нам понадобится такая хорошая программа, как Adobe Photoshop, причем подойдет практически любая версия. Особых знаний работы с фотошопом для этого т.с. трюка не НАТО, все делается буквально в пару кликов.

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

Что есть правильная посадка в кресле?

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

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

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

Решение — правильная поза. Как ее достичь? Причем совершенно штатными средствами, без адских подлокотников или кресел за полторы тысячи евро?

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

Итак, Scrum, это популярная (модная, если хотите) сегодня методология ведения программных проектов. Другими словами, как управлять командой разработчиков, что бы программный проект завершился успешно. Что и как документировать, как, с кем и как часто обсуждать детали проекта, как ставить задачи людям и как контролировать результат. Всё это попадает под термин “методология управления программным проектом”.

Вам понятно? Отлично! А теперь…

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

Зачем нужен Feed43?

Наш сервис дает возможность вам самим создавать RSS-каналы из любых веб-страниц. Фактически, Feed43 предоставляет универсальный API на основе RSS к любому сайту, любой странице и даже любой части страницы.

• Хотите читать новости с сайтов, не предоставляющих RSS?
• Хотите предоставлять разнообразные RSS-потоки для читателей вашего собственного сайта/блога, не заморачиваясь при этом с программированием?
• Хотите отслеживать список самых кассовых фильмов, количество полученных Россией олимпийских медалей, популярные записи в блогах?

Все это теперь возможно.

Обычно для работы с mySQL я использовал «phpmyadmin», но сегодня мой взор был направлен на новое решение «SQL buddy», я скачал, загрузил на свой сервер, и…
И это просто супер! Такой и должна быть удобная работа с БД!

Возможно «SQL buddy» не имеет столько расширенных функций как «phpmyadmin», но для рутинных и небольших работ она прекрасно подходит.

В рамках поддержки блога разработки под Mac OS X, я представляю свою статью о низкоуровневой разработке под Mac OS X. Обычно тема разработки драйверов не столь популярна, однако и здесь Mac OS X выгодно выделяется из ряда прочих операционных систем. Да, писать драйвера для Mac O S X – просто! Проще чем когда-либо ранее!