Как стать автором
Обновить

Комментарии 33

не могу понять почему я раньше не знал об этом FM. будем изучать
наверно, потому что Вам либо не интересна тема вообще, либо вы уже очень сильно сидите на другом фреймворке и не смотрите по сторонам… так как будь вы хоть немного заинтересованы знали бы как минимум о symfony, zf, ci ну и еще парочке…
Наверное, стоит отнести в блог Symfony. А то потом тяжко искать. И страно, что комментариев немного, а ведь уроки те — суть важная для понимания сего фреймворка. Я долго ждал, когда будет версия FM совпадать с докмуентацией.
Перенести пока не могу, у меня не хватает на это кармы
А сейчас?
большое спасибо)
НЛО прилетело и опубликовало эту надпись здесь
Ну так давайте переводить этот туториал на проекте, например, translated.by
На translated.by уже создан перевод с заголовком «The Jobeet Tutorial Day 1: Starting up the Project», но по какой-то причине он не публичный.
Как вариант можно создать альтернативную версию перевода, которая будет публичной.
НЛО прилетело и опубликовало эту надпись здесь
Вообще у вас перевод неправильный. Jobeet — создание доски объявлений/сайта вакансий.
У них написано: Enter Jobeet, the 2008 symfony advent calendar tutorial!
Что вовсе не означает, что Jobeet календарь событий. Суть заключается в том, что Jobeet — учебник, который будет регулярно публиковаться/дополняться в 2008
Вы правы, поправил. Просто в посте Фабьена про это ни слова.
Я был бы очень благодарен за перевод цикла всех статей, т.к. сейчас выбираю фреймворк для расширения своих знаний.
Задаю себе вопрос, как успевать изучать все эти новопоявляющиеся фреймворки? Последняя пара лет принесла лавину новых решений. Наверняка там есть много хорошего, но… Тут либо работать и давать результат, либо заниматься «ростом над собой».
А кто-то успевает хотя бы быть в курсе (я даже не говорю использовать) новое?
честно сказать мало кто успевает учить все то новое что сейчас появляется ))
но если вы пробовали работать в такими решениями как Django, вам однозначно понравится контроль фреймворка из cmd или терминала.
Собственно в своё время, когда началось брное появление Rails-like фреймворков на PHP (CakePHP, Bisquit, и прочее) я обратил внимание на symfony, бегло проглядев за пару часов Askeet.

Вообще я регулярно трачу время и смотрю на новые фреймворки, на их новые версии. Всегда можно углядеть полезные приемы, архитектурные решения и пр.
НЛО прилетело и опубликовало эту надпись здесь
А где можно посмотреть демо админской стороны данноой CMF?
backend вы генерируете сами, он может выглядеть по разному это ведь не CMS
вот список решений на symfony trac.symfony-project.org/wiki/ApplicationsDevelopedWithSymfony
меня особенно впечатляют сайты по типу MTV разных стран
СУПЕР!!! Это то что мне нужно было, так по книге the Definitive Guide to Symfony 1.1 действительно немного проблематично было учится из-за отсутствия времени, а теперь я с удовольствием пополню сообщество symfony.
Черт. Только-только собрался разобраться в CI, одним плюсом которого является неплохая документируемость.
Что же теперь выбрать? Вопрос не холивора ради, а познания истин для.4
тут скорее всего вопрос удобства, а не плюсов и минусов
мне очень нравятся исполняемые bat файлы для работы через командную строку(схожесть с Django) и многоуровневая конфигурация. Именно поэтому я и выбираю Symfony, да и эти цифры тоже не могут не радовать — 353 плагинов
Так а сильно, по-вашему, CI уступает Симфонии?
Мне как-то необъяснимо, подсознательно CI нравится больше =)
ну я не щупал CI основательно ниче не могу сказать, одначно, да и не люблю эти споры, вещи и там и там одинаковые можно сделать в симфонии идет упор rapid application development(как в Django и RoR) т.е. много вещей строится на полуавтомате в помощью командной строки, т.е. вы можете писать вручную струтуру mvc(создавать файлы, каталоги для моделей итд.) а можете на автомате с помошью одной команды и потом добавлять функции, к примеру вам не надо создавать таблицы в БД вы просто это делаете в конфиге yaml(xml или json) и symfony генерирует БД при этом если нужно указываете ей чтобы был была сгенерирована модель CRUD для конкретного приложения к примеру блога и с ходу можно добавлять посты, это действительно очень круто имхо
вот можете посмотреть как Фабиен админку делает symfony-project.org/screencast/admin-generator
Сколько много умных, но не знакомых мне слов =) Когда провикипежу, подумаю. Спасибо =)
Я когда работал с CI, чувствовал себя весьма неуютно. Что мне нравится в Symfony, так это многоуровневая конфигурация, веб дебаг тулбар и отличная документация (правда относительно версии 1.0, у 1.1 есть некоторые проблемы, однако 1.2 судя по-всему будет документирована на самом лучше уровне). Сама организация хранения файлов гораздо более удобна, когда речь идёт о больших проектах.
Спасибо за комменты, сегодня же ставлю Симфонию =)
Ах да, пресловутый decoupling в 1.1 очень понравился — я смог выдрать механизм форм и использовать в своем стороннем проекте (да, могбы взять ZF, но с ним я знаком слабо).
IMHO: symfony framework — это самое приближенное что есть для php потипу техже RoR для Руби (ну а дял чего еще-то :))) ) или типа Django для Phyton, однако оговорюсь, не есть тоже самое, Фабъен был пропитан этим духом больше других фреймворкостроителей!
Я тут опять по ночам не сплю… и всё проспал. Но тем не менее:
symfony.artsofte.ru/blog/post/id/31

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

1. Переводной документации всегда будет мало.
Для полноценной работы с symfony потребуется прочитать не только документецию и туториал, но и cookbook, wiki, forum, документацию по ORM (Propel или Doctrine), общение в группах и т.п. Все это перевести не реально.

2. Для начала работы нужны советы.
При изучении фреймворка требуется поддержка сообщеста. Часто возникают ситуации, которые слабо раскрыты в документации или туториале. Маленькое локальное сообщество — маленькая поддержка, и часто ответов просто не дождаться :-(. Поэтому неизбежно прийдется идти на сайт symfony и уже там в форуме искать ответы, а если их нет — постить свои вопросы.

3. База знаний должна быть в одном месте, доступна всему сообществу, а значит должна быть на одном языке.
Вопросы, ответы, предложения, патчи — это все должно быть в одном месте. Если вести языковые комьюнити, то неизбежно знания будут застревать в них, и перестанут быть доступны всем… Это приводит к необходимости несколько раз решать одни и те же задачи. Зачем?

Поэтому перевод документации — это костыль для инвалида. Инвалида конечно можно им поддержать, но вот качественного разработчика, использующего фрэимворк, не получить!
Отсюда вывод — хочешь работать всерьез — учи язык!
Технический английский получить не сложно — месяца три позаниматься и все. По-моему цена не велика.
Коллега, в Ваших словах есть доля истины, но перевод не помешает.
Кол-во текста в «Джоб-ит» будет довольно большое, а например мне в условиях жуткой нехватки времени гораздо быстрее пробежать глазами перевод maddog-a чем читать англ. версию.
К тому же некоторые читая англ.версию просто могут неправильно перевести довольно тонкие моменты в описании.

Насчет Симфонийского сообщества, конечно надо приглядывать за англоязычным сегменом, но опять же порой сложно понять что хочет сказать некий албанец…
Для меня лично наиболее полезным является несколько контактов симфонистов в аське-скайпе.
Я считаю, что нельзя считать нормальным программистом того, кто не знает хотя бы технический английский. Но и не соглашусь, что не нужно переводить. Самым оптимальным есть перевести jobeet + guide. А дальше — если будет нужно, человек разберется сам.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории