Я занимаюсь разработкой web-проектов сравнительно недавно. И с первых же дней работы мне пришлось столкнуться с системами контроля версий, и, как вы уже догадались, это был Subversion. Для меня сначала было не совсем понятно, что такое trunk, brunch и tag. Вернее, что это такое мне объяснили, а что с этим делать — нет.

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

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

Первое, о чем я хочу сказать — вы можете организовать структуру хранилища и работать со структурой так, как вам удобно. Но не нужно удивлять тех людей, которые будут работать в проекте после вас. Как и в любом деле — в организации структуры хранилища в svn существует хорошая практика, зарекомендовавшая себя временем. И об этой практике я хочу немного рассказать.
Читать дальше →

Я занимаюсь разработкой web-проектов сравнительно недавно. И с первых же дней работы мне пришлось столкнуться с системами контроля версий, и, как вы уже догадались, это был Subversion. Для меня сначала было не совсем понятно, что такое trunk, brunch и tag. Вернее, что это такое мне объяснили, а что с этим делать — нет.

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

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

Читать дальше →

Предисловие

За несколько лет успешной и не очень работы с различными Web-CMS у меня появилось непреодолимое желание научиться писать веб-проекты на более «высоком» уровне. Хотя технически все же правильнее будет сказать «на более низком». Крайне не хватало для реализации своих идей функционала известных движков. А разбираться в API и исходниках каждого (для написания расширений и модулей) мне показалось слишком муторным.

И тогда мой взгляд упал на веб-фреймворки. Конечно же, на наиболее популярные: Ruby on Rails, Django (Python) и php-шный Symphony. Желание изучать последний отпало почти сразу — когда работал в офисе, от коллеги-программиста, писавшего серверную часть проекта на связке Php+Symphony+Doctrine, слышал слишком много нецензурных слов.

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

Я попробовал. И то и то. По чуть-чуть, но с выбором быстро определился. Итак, Rails 3.0 против Django 1.2 по версии начинающего свой путь веб-программиста.


Читать дальше →