Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Когда я писал топик об использовании шаблона Command для организации RPC-вызовов в GWT то упоминал об MVP-паттерне для построения архитектуры GWT-проектов. Сразу после выступления товарища Ray Rayan’а с докладом о проектировании сложных приложений на GWT трудящиеся по всему миру принялись реализовывать озвученные идеи в виде библиотек и фреймворков. Результатом этих трудов стали средства, позволяющие применять как некоторые моменты MVP-подхода (GWT-Presenter) так и его целиком (Mvp4G). Это все замечательно, но мне лично (уверен, что и остальным GWT-разработчикам) хотелось бы иметь стандартизированный (если можно так сказать) фреймворк/подход для организации GWT-приложений по MVP-схеме. И вот команда, которая отвечает в Google за GWT, наконец-то в версии 2.1 наряду с остальными вкусными плюшками предложила встроенный MVP-фреймворк.
В данной заметке я постараюсь осветить основные моменты встроенного GWT MVP-фреймворка. Как пример будет использовано небольшое приложение, построенное с применением этого подхода.
Данная заметка является вольным трактатом (GWT MVP Development) и на уникальность подхода никоим образом не претендует. Если кого-то заинтересовало такое немаленькое введение

Примечание переводчика: Некоторое время назад я прочитал замечательную статью на Medium.com. Автор статьи Samuel Thomas Davies взял за основу исследования профессора Стэнфордского университета Би Джей Фогга об изменении поведения. Сегодня я хочу поделиться ее переводом с хабрасообществом.

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

Очевидно, что делать это намного сложнее, когда вы совершаете ошибки, которые достаточно банальны, но при этом часто недооценены или просто-напросто проигнорированы ввиду их неприметности.

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

Многие из вас знают, как эффективно повышает производительность использование горячих клавиш, шаблонов кода и очень клёвой строки поиска (Quick Access), но я бы хотел рассказать о десяти возможностях, которые знают не все.

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

Разработка ПО – нелинейный процесс

Разработка программного обеспечения — нелинейный процесс. Если на проект выделено 5 разработчиков, которые за 5 месяцев должны разработать продукт (25 чел./мес.), то 25 разработчиков не смогут сделать эту же работу за 1 месяц (те же 25 чел./мес.).