Веб-девелопмент

merb/rails

Python/Werkzeug.

python/django

И чего же вы против пхп, при опыте работы с вебом, имеете? :-)

Да, по теме

Perl/Catalyst

:-)

Python + Django.

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

А не подскажешь ничего на нашенском по rails почитать.. желательно введение и базовые вещи.

по сабжу: ASP.NET

Если только аналоговое: "Путь rails" http://www.books.ru/shop/books/611002 и "Гибкая разработка..." http://www.books.ru/shop/books/548314

Путь Rails я где-то видел у кого-то.. надо спи^Wпозаимствовать.

Язык не имеет значения. Имеет значение воркфлоу.

Вот я асилил туториал к симфони на 300 страниц, еще раз убедился, что похапе сплошное кг/ам, что нет в жизни счастья, однако теперь скорее всего буду придерживаться некоторых тамошних идей и правил. А язык/фрейморк тут можно использовать любой.

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

Селектнул, зашаблонил, отдал юзеру, селектнул, зашаблонил, отдал юзеру - романтика...

удваиваю каталист

Common Lisp / Weblocks (;

J2ee же вестимо, курить веб-ориентированную часть спеки (всякие jsp, servlets, jsf).

Python/Django, если пишешь для себя. Подходящих дешёвых хостингов пока относительно мало, но их число постепенно растёт. Если работать на дядю - извиняйте, там php, за редкими исключениями - Perl или Python.

Абсолютно верно!
За это ненавижу своих сотрудников, они никогда не изучают фреймворки и технологии вообще с которыми не работают.

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

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

java/spring : )

удваиваю джанго

для начинающих лучше даже groovy/grails

> За это ненавижу своих сотрудников, они никогда не изучают фреймворки и технологии вообще с которыми не работают.

А изучать надо не фреймворки, с которыми не работаешь, а бест практисес от крупных компаний. Туториал от симфони под это дело попадает.

>откуда у динамических языков такая популярность?

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

> Кстати, откуда у динамических языков такая популярность? Они, как правило, интерпретируемые, что позволяет наблюдать результат сразу после правки исходников (как анипод компилируемым, где приходится ждать пока программа скомпилируется). C#, хоть и компилируемый по природе, но благодаря платформе ASP.NET мимикрирует под интерпретируемых, и тоже популярен. :)

JavaScript/jQuery

python django/webpy

А фреймворк это не решение проектирования?

>django

Вот что касается джанги, я считаю не стоит с нее начинать. Если начинать изучение с чуть более низких уровней, скажем, собрать на коленке свой фреймворк из компонентов типа ORM ("M"), шаблонизатора ("V") и обертки вокруг реквеста и респонза ("C"). Джанга слишком уж эгоцентрична и подходить к ее изучению нужно уже с хорошим знанием матчасти (пайтон в целом и вебдев на нем в частности), чтобы не заклинило моск джангой навсегда.

> А фреймворк это не решение проектирования?

Это просто инструмент. Я могу взять десяток библиотек, настрогать сотню функций вида getHTMLLinkCodeForVideoEmbedPlayer(url), и сложив все это горкой назвать "фреймворк". Толк от изучения будет?

> Если начинать изучение с чуть более низких уровней, скажем, собрать на коленке свой фреймворк из компонентов типа ORM ("M"), шаблонизатора ("V") и обертки вокруг реквеста и респонза ("C")

Да чо мучиться, достаточно 5 лет на голом CGI без готовых модулей и жизнь пойдет. А потом почитать маны к ораклу и понять, что все нужное уже там есть. Потом почитать маны к j2ee и тоже понять, что все нужное уже давно написано. Ну и php использовать не как язык программирования, а как шаблонизатор, которым он и задумывался.

Уймись, я не претендую на ынтырпрайзность. Это был просто совет для тех, кто решил начать изучать пайтон и вебдев с ним.

Ну я бы так не сказал.
Вот например в CodeIgniter MVC реализован по одному, в Django оно же совсем по другому. Знание этих подходов и есть знакомство с уже существующими реализациями данного патерна. Слой для работы с БД у всех по разному. Я считаю что эти знания очень полезны.
Да и знакомство с любой библиотекой дает, как минимум, понятие про проектирование API, что необходимо перед разработкой своей библиотеки.

> Вот например в CodeIgniter MVC реализован по одному, в Django оно же совсем по другому

И вот сидит новечек на стуле и размышляет: "нету равновесия в мире этом, даже MVC всяко трактуют". Ну и чего ему выбрать, какого стиля придерживаться?

Для начала можно отталкиваться от целей. Зачастую цель такая: "сбацать говносайт за 50-500 баксов и забыть как страшный сон". Ну примерно как глагне кодеигнера: for PHP coders who ... who lives in the real world of shared hosting accounts and clients with deadlines. В этом случае и фреймворк то не нужен, берем жумлу (или любой другой говнодвиг) и лабаем на ней. Быстро, дешево и в дедлайн "до утра" успеваем.

Другое дело, когда надо забацать что-то высоконагруженное или слишком эксклюзивное, тут уже другие подходы, зачастую с "shared hosting accounts and clients with deadlines" плохо совместимые. Это как карьерный экскаватор на улицах города. Конечно круто, но слишком дорого, много ограничений, а в конечном счете смысла не имеет.

> Знание этих подходов и есть знакомство с уже существующими реализациями данного патерна. Слой для работы с БД у всех по разному. Я считаю что эти знания очень полезны.

Лучше знать РАЗНЫЕ паттерны, мир на MVC не заканчивается, да и за веб-сервером может быть целая инфраструктура, которая может включать в себя сразу несколько принципов. И это гораздо полезнее, чем знать различия работы с БД.

Что такое современный сайт? Это хранилище информации. Раньше это было статичное хранилище информации в HTML, нынче хранилища модно делать динамичными, дабы юзеры сами правили информацию (регистрировались, что-то постили, правили), причем с разными ACL, пре- и пост-обработками.

Теперь вспоминаем, что такое СУБД и чего оно должно делать? Для чего СУБД создавались? Именно для хранения информации, для управления и работы с ней. В нормальных СУБД есть и хранимые процедуры (пре/пост-обработка), и разнообразные интерфейсы, и расширяемость, и блекджек, и даже дамы легкого поведения. Остается только транслировать REST-запросы в хранимые вызовы, а ответ базы в HTML.

Но вот посмотришь на современные движки с ихними ORM и кучами велосипедов над нижележащей СУБД, и вообще не понимаешь, как оно вообще там ворочается. Ах да, они же расчитаны на шаред хостинг, где нормально не развернуться...

> Да и знакомство с любой библиотекой дает, как минимум, понятие про проектирование API, что необходимо перед разработкой своей библиотеки.

Ага, но есть нюансы... Я видел несколько библиотек, где юникод разбирали "а вот тут просто отбрасываем каждый второй байт и получаем текст". Потом приходилось править. Будет ли опыт от изучения такого хорошим?

>Но вот посмотришь на современные движки с ихними ORM и кучами велосипедов над нижележащей СУБД, и вообще не понимаешь, как оно вообще там ворочается. Ах да, они же расчитаны на шаред хостинг, где нормально не развернуться...

Хех, ты предлагаешь вместо современных движков с ОРМ использовать на шейрд-хостингах оракл и j2ee? :)

> И вот сидит новечек на стуле и размышляет: "нету равновесия в мире этом, даже MVC всяко трактуют". Ну и чего ему выбрать, какого стиля придерживаться?
Ну это уже на его совести, со временем он сам поймет что и для чего лучше. Это ровно также как и с дистрами, сидит новичок и думает о том что Линукс это не ОС, а дистрибутивов GNU сотни, и какой же ему поставить. :)

> Для начала можно отталкиваться от целей.
> ...
Я просто под целью изучения имел ввиду развитие как программиста, проектировщика систем. И абсолютно согласен что для клепания сайтов/магазинов гораздо "полезней" будут совсем другие знания. Знаю людей, не знающих слов ORM, рефакторинг, MVC, но освоивших Джомлу) зарабатывающих на фрилансе больше чем офисе хотя с намного большими знаниями. Тут просто дело все в том что человек хочет достичь, как развиться. И я не говорю что всем разработчикам эти знания будут одинаково полезными.

> Лучше знать РАЗНЫЕ паттерны, мир на MVC не заканчивается...
Ну это понятно, я просто данный случай в пример привел. Я же не говорю что MVC вселенская истина.

> Ага, но есть нюансы... Я видел несколько библиотек, где юникод разбирали "а вот тут просто отбрасываем каждый второй байт и получаем текст". Потом приходилось править. Будет ли опыт от изучения такого хорошим?
Я считаю, что абсолютно любой опыт полезен, даже неудачный, -- "как нельзя делать". И неужели в той библиотеке не было что-то нового и интересного? И опять же, не весь опыт/знание _одинаково_ полезны, но полезны практически все, они расширяют кругозор, они учат новым подходам к старым задачам, с которыми казалось бы уже ничего нового не придумать.

> Хех, ты предлагаешь вместо современных движков с ОРМ использовать на шейрд-хостингах оракл и j2ee? :)

Только вместо этого получаются велосипеды, эмулирующие оракл на похапе :)

> Знаю людей, не знающих слов ORM, рефакторинг, MVC, но освоивших Джомлу) зарабатывающих на фрилансе больше чем офисе хотя с намного большими знаниями

Многие знание - многие печали. Я вот завидую им и жалею, что начинал не с похапе. Ну стошнило меня тогда, а перловка сразу понравилась... Сейчас даже не знаю, на чем простой сайт смастерить. Похапе религия не позволяет, перл считается устаревшим и заказчики на него презрительно смотрят, педон я ниасилил из-за отступов, хотя на джангу дрочил довольно долго. Посещают мысли о написании своего велосипеда: обработчик форм + шаблонизатор + прозрачная работа с БД, т.е. что, чем когда-то был (задумывался?) похапе...

> Я считаю, что абсолютно любой опыт полезен, даже неудачный, -- "как нельзя делать"

скорее "даже они так делают, значит и мне так можно".

что-то я печален...

Ты явно не в теме :)

btw, похапе не нужен.

>что-то я печален...

Ну еще бы, печально, надо полагать, чувствовать свою никчемность как специалиста.

> Ты явно не в теме :)

Раскрой тему :)

> btw, похапе не нужен.

Раскрой и эту тему :)

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

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

Попробуй RoR, если тебе так отступы не милы.

>Хех, ты предлагаешь вместо современных движков с ОРМ

это вы на какие движки намекаете?

Я ни на что не намекаю, я цитировал EmStudio: "Но вот посмотришь на современные движки с ихними ORM и кучами велосипедов над нижележащей СУБД... <далее сотни ненависти>"

:)

> Они нужны только там, где они нужны. Вот скажем бульдозер -- очень функциональная и мощная машина. Однако это не значит, что можно всем срочно выбрасывать свои легковушки и пересаживаться на бульдозеры :)

Про это я уже писал выше. Однако, если бульдозеры делать компактными... Хм... Что-то в этом есть...

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

Когда я увидел MAX_FILE_SIZE, складывание файлов в директорию по умолчанию, глобальные переменные из запроса, изобретение в формах с именами[], языковые конструкции и прочие прелести php2, то меня тоже стошнило.

Но если посмотреть на скорость и простоту разработки, то похапе становится очень приятным. А если в формах сделать что-то вроде <input type="hidden" name="do" value="INSERT INTO ..... VALUES (this.form.name, this.form.message, .....)">, то с серверной стороны скрипты будут почти не нужны, ибо зачастую кроме интерфейса к БД ничего и не надо... Разве это не прелесть? Остается только решить проблему с безопасностью и можно делать говносайты в массовых количествах.

Вощем похапе мне нравится все больше и больше, и это после 8 лет работы с перлом... Может у меня мозги поплавились, или я просто постиг дзен похапе?

> Попробуй RoR

Смотрел. Не встало. Да и руби по скорости был еще хуже похапе, хотя недавно вроде поправили.

http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

Смотреть на столбец ORM

>А если в формах сделать что-то вроде <input type="hidden" name="do" value="INSERT INTO ..... VALUES (this.form.name, this.form.message, .....)">

OMG! А потом удивляются дырявости пыхпых-сцайтов...

>Остается только решить проблему с безопасностью

Первый пункт решения этой проблемы -- грамотная архитектура. Первая цитата не шибко под это определение подходит.

>похапе мне нравится все больше и больше, и это после 8 лет работы с перлом

Поищи эпический опус на тему php vs perl. Даже если мнение свое не изменишь, кругозор расширить и взглянуть с другой стороны будет полезно.

>можно делать говносайты в массовых количествах

Да, ты действительно постиг дзен похапе.

>> Попробуй RoR

>Смотрел. Не встало. Да и руби по скорости был еще хуже похапе, хотя недавно вроде поправили.

Мне тоже не очень. Но не из-за скорости, а из-за синтаксиса неоднозначного и неочевидного, эдакого синтаксиса с намеками.

> OMG! А потом удивляются дырявости пыхпых-сцайтов...

Ну я же для примера... Да и от MAX_FILE_SIZE не слишком далеко ушло. Заменяем sql-запрос на его ID, а сам запрос храним на сервере хоть в текстовом файле - легче стало?

> Первый пункт решения этой проблемы -- грамотная архитектура.

И это конечно же... MVC??????77 Ты раскрой тему то...

> Поищи эпический опус на тему php vs perl. Даже если мнение свое не изменишь, кругозор расширить и взглянуть с другой стороны будет полезно.

Дай линк, тут оные постоянно. Хотя я и так с разных сторон смотрел вроде, правда сторону похапе принял недавно.

> Но не из-за скорости, а из-за синтаксиса неоднозначного и неочевидного, эдакого синтаксиса с намеками.

Это тоже сыграло далеко не последнюю роль.

и? сможете сравнить по этой таблице Propel и GORM/Hibernate?

>Смотрел. Не встало. Да и руби по скорости был еще хуже похапе, хотя недавно вроде поправили.

попробуйте grails

JSF