Евгений

Мне кажется, что "лучше" или "удобнее" — субъективные метрики. И не очень абсолютные. К примеру, меня бесит grappelli (приложение, изменяющее внешний вид админки), а кому-то она наоборот нравится. Mezzanine, насколько я помню, grappelli использует. Мне это покажется дичайшим минусом, а кому-то плюсом.

Личный опыт: довелось довольно плотно поработать с django-cms и fein. Они, в общем-то работают по одному принципу, хотя и используют разную терминологию (django-cms для расширения функциональности страницы плагины, которые помещаются в плейсхолдеры, а fein — контент-тайпы и области соответственно), суть примерно одна. Хоть и слегка по-разному реализовано.

Сейчас ключевое отличие djnago-cms и fein в том, что первая, начиная вроде бы с версии 3.х, перешла целиком на фронтэнд-редактирование контента. Админки как таковой нет, вместо неё редирект на страницу с включенным редактированием. А Фейн управляется из админки, как и django-cms ранних версий.

Для программиста обе cms относительно удобны и легки для разработки и предоставляют интерфейс для написания плагинов (или контент-тайпов, в зависимости от). Но если лезть глубоко под капот, то в django-cms всё гораздо сложнее в плане моделей и отношений. Поэтому очень мудрым шагом со стороны её разработчиков было предоставить "низкоуровневое" апи с функциями вида create_page(), которое на деле создаёт десяток записей в десяти таблицах :-)

По поводу удобства редактирования контента, опять же субъективно: оба ужасны. Наверное, фейн даже в большей степени. Но при этом он более очевиден. Чего не скажешь о фронтэнд-редактировании django-cms, где вообще без поллитры не разобраться: сначала перевести страницу в режим редактирования, потом переключить непонятный тумблер контент\структура (или что-то такое, сейчас точно не помню), потом выбрать редактируемый плагин... потом не запутаться в кнопках сохранения и публикации, и так далее. Мой коллега придерживается мнения, что показывать такое пользователям просто нельзя.

Кстати, пользователь легко сможет сломать дерево сайта (вплоть до вызова 500-й вместо захода на любую из страниц), просто активно перетаскивая в админке ноды дерева туда-сюда. Это касается и fein, и django-cms.

Что до mezzanine. Запомнилось так: использует grappelli, зачем-то есть встроенные магазин и блог, которые сааавсем не на каждом сайте нужны. Плюсов не запомнил, снёс. Хотя сейчас, открыв ради любопытства документацию, вижу что-то про custom content types, так что, вероятно, будет всё то же самое, что и fein/django-cms, но в зелевноватых тонах grappelli. И с магазином :-)

1. Создаю каталог для проекта
   
2. Инициализирую Bower
   
3. Устанавливаю нужные пакеты, например, Twitter Bootstrap, Angular, jQuery и т.д.
   
4. Ставлю Grunt, плагины для него и т.д.
   
5. Запускаю EMACS и создаю index.html
   
6. С помощью Emmet создаю шаблон, который уже начинаю заполнять.
   
7. В каталоге src создаю папки less, js и т.д.
   
8. Попутно пишу задачи для Grunt
   
9. Если в выбранном фреймворке не хватает какого-либо класса для стилизации элемента, сначала описываю стили прямо в шаблоне, в свойстве style. Затем при необходимости выношу их оттуда в LESS в виде одного или нескольких классов.
   
10. ??????????
    
11. PROFIT!!!
    

Вы можете сделать все что угодно, но главное придерживаться рекомендуемых размеров шрифта (не меньше 11pt) , области нажатия кнопок и размеры Navigation Bar и Tab Bar.

Максим все можно! Да будет не просто, но вы же не спрашиваете будет ли это просто, вы спрашиваете - реально ли, так вот - очень даже реально.

Сами в удаленном регионе сидим, работы очень мало квалифицированной, it-шной в городе. Сами собрались в команду, подучили рельсы и куём.

Всеё банально просто. Java компилируется в байткод, а не в ассемблер. Байткод интерпретируется виртуальной машиной JVM, которая при необходимости делает компиляцию в нативный код процессора (технология JIT - Just-in-time compilation).
Другими словами, для того чтобы получить нативный код нужно запустить байткод внутри JVM. Именно поэтому никто не пришет на java драйверов и прочей низкоуровневой хрени. С другой стороны, чтобы эту хрень писать на java, нужно чтобы было одно из двух условий:
1) либо процессор напрямую поддерживал спецификацию JVM (со всем барахлом типа GC, memory allocation^ resource management)
2) либо операционная система поддрерживала в ядре спецификацию JVM (с тем же самым барахлом)

Ну и не нужно говорить, что язык барахло, если на нем нельзя писать драйверы и секции для MMU. Есть еще десятка два языков, которые это не поддерживают, например все X.NET или erlang^ python и т.д.
Java для прикладного программирования, а C/C++/D/ASM и прочее - для машинного.

Очень хорошее начало, давайте определимся.
1) Нужен дистрибутив, который достаточно легко ставится, имеет большое комьюнити, достаточную документацию
2) Дистибутив должен обладать как клиентским вариантом, так и серверным
3) Дистрибутив должен быть известен и широко распространен
4) Иметь все необходимое для разработки
5) Поддерживаться производителями и разработчиками стороннего ПО (а есть и такие)!

По хорошему, данным целям отвечают всего два дистрибутива и их клоны - RedHat и Debian. Дистирубивы на первый взгляд достаточно сильно различаются настройками и установкой софта, но внутри белее или менее похожи.

Из Debian и его клонов рекомендую Ubuntu, именно для неё сейчас самая лучшая документация (и на русском), поддержка и комьюнити, а сам дистрибутив включает в себя все свеженькое и новенькое в плане поддержки железа и новых версий софта.
- www.ubuntu.com

Из RedHat и его клонов настоятельно рекомендую CentOS как клиент/серверную платформу - документация, поддержка железа комьюнити.
- www.centos.org

Оба дистрибутива бесплатные, более чем полностью.

PS. Наверное здесь сейчас будут предлагать кучу экзотики - не ведитесь на это! Учиться ездить нужно на простых автомобилях, а не на тюнингованных. Да и эти дистрибутивы (RedHat/Debian) именно мейнстирм, в которых все вылизано и просто работает.

изучай дальше java core, а так же параллельно лучше ознакамливаться с технологиями, с которыми придётся взаимодействовать раньше. то есть для работы с базой надо jdbc и знания по самой базе нужны, без этого никак. IDE - изучается в процессе работы (эклипс или идея, но я больше склонен к идее).
тут уже можно начинать изучать контроль версий (свн легче для восприятия, чем гит, хотя кому как. но гит, имхо, более гибкий)
после начинай постепенно веб, MVC, хибер со спрингом можно взять и навалять небольшое приложение (тут тебе уже помогут основы самого языка и базы). для сборки легче использовать мавен, на минимальном уровне (что бы только собирал, хотя бы). после поднимай взаимодействие на веб морде.

Забавно читать ответы.

Когда читал Философию Java, автор высоко оценивал python. И не с проста. Как и Java, у Python свои плюсы.

По производительности что Python, то и Java примерно равны. Python имеет "нативный" byte-code, если так можно выразиться (не смотря на то, что его портировали и на CIL, и на JVM, и на сам Python). Так что здесь паритет.

По удобству зависит от проекта и задач. Если цель - сделать как можно быстрее, то Python явно удобнее. Ибо можно набросать прототип в интерактиве, немного подправить его и вауля - проект "готов". Если цель надёжность - наш выбор Java: статическая типизация и компилируемость выявляет сотни ошибок ещё до запуска приложения.

Стоит заметить, что вэб в Java развит очень сильно. Причём настолько, что он просочился до клиентских вэб-приложений (и умер лет 10 назад), хотя backend всё равно в разы сильнее. Что это значит? Это значит, что для Java есть множество отличных фреймворков, ориентированных на web. Каноничная реализация ООП позволяет использовать паттерны банды четырёх "из коробки". Интерфейсы, если ими уметь пользоваться, решают. Python же не создавался как web-движок, а создавался просто как удобный инструмент для быстрого программирования как прикладных, так и теоретических задач. В этом помогает всё - и сахарный синтаксис, и крутейшие итераторы, и пресловутый интерактивный режим, и невероятные slice'ы, и неплохие лямбды, и красивый код. RoR, если говорить о языке фреймворка, так же сильно похож на Python, но магии в нём много больше. Но Python-приложения тяжко отлаживать. Можно пару лет вести баг, который окажется из-за того, что мы не проверили возможность преобразования объекта к строке в аргументах. Динамическая типизация, причём очень хардовая из всех, наверное, это и дар и проклятие.

Собственно, если вопрос стоит "стоит ли изучать", то да, конечно стоит. Как и Java, Python - мультипарадигмальный язык, и те практики, которые Вы изучите в Python несомненно улучшат код в Java.