Мербовцы на уровне фреймворков сделали именно то, о чем говорил Дэйв Томас на последнем RubyConf. Форкнули фреймворк, сделали изменения, протестили их и сейчас собираются заливать обратно. Этот мэрдж и есть результат.
Вывод распечатать, заламинировать и в рамочку на стену. Если когда-нибудь хоть половина компаний будет руководствоваться такими принципами, мы будем жить в совсем другой стране. Причем это касается не только веб разработки.
Ваше описание проблемы уродского кода сгенеренного автоматически я понял. Для решения этой проблемы есть два пути.
Путь первый — просветительская работа среди разработчиков использующих надстройки над языком с целью объяснить им идеи JS и как этот язык правильно использовать. Правильно используя язык весь код становится красивым.
Выход второй — совершенствование самих надстроек для генерации более качественного кода. В результате получим качественный код в приложениях (пусть даже и менее качественный чем идеальный код написаный вручную)
А вот дальше вы сосредоточились на первом пути. А ребята использующие .NET, насколько я понял, вместе со своим фреймворком пошли по второму пути и постепенно избавляются от страшненькой кодогенерации первых версий фреймворка. Не думаете же вы всерьез, что они были в восторге от ужасных значений id создаваемых раньше?
Вы идете к одной цели(красивому коду) разными путями. Вам нравиться JS и вы пишете красивый код на нем. Дотнетчикам нравится их фреймворк и они его используют, а создатели фреймворка постепенно приводят в чувства кодогенерацию. Вот собственно и все.
Не забывайте пожалуйста о том, что это сравнение _старта_ работы на бирже. То есть, грубо говоря, что помогает и что мешает получить первый заказ и первый отзыв.
Детали платежей, настройки Тим, предоставляемый SVN и другие вкусности я постараюсь описать в следующей статье.
Это верно. Но верно и то, что любой инструмент, включая языки программирования, формируют у разработчика вкус/привычки и т.д. Связь получается в обе стороны.
VDS обычно дают в чистом виде без каких-либо дополнительных настроек. Я же имею ввиду возможность дать пользователю выбирать конфигурацию софта, точно также как он выбирает hardware. Тогда десяткам пользователей не нужно будет совершать одни и те же действия чтобы настроить себе, например, php+apache+mysql+svn+ftp или ruby+rubygems+rails+mongrel+mongrel_cluster+postgresql+git. Понятно, что потом нужно будет все донастраивать, но времени это по-любому будет занимать меньше.
Хостинг как одежда: кому-то нужно больше, кому-то — меньше. Спорить можно до хрипоты, но 150-килограммовый качок и субтильная 60-килограммовая девушка в размерах одежды сойтись не могут.
На мой взгляд, лучше всего было бы для каждого заказчика конфигурировать систему индивидуально. Все-таки вещи типа Ruby/Rails, Python и XSL нужны далеко не всем. Или, если не конфигурировать под каждого отдельную систему, то можно создать 20-30 разных вариантов настроек вместо 3-6 обычных.
а я бы это интерпретировал так:
под ruby есть такое кол-во готовых прикладных библиотек, что пользователи уверены в том, что найдут то, что им нужно и часто ищут код
Дополнение к пункту 3:
Если в ТЗ четко написано про адаптивную верстку, то верстальщику понадобятся все варианты раскладки, а не один.
4. Мы живем в неидеальном мире где пользователи могут допускать ошибки. Изображение этих ошибок тоже должно располагаться на странице и показать их можно очень по-разному. Как именно это сделать тоже должен думать дизайнер, а не верстальщик/программер/уборщица тетя Маша.
Пока я собираю идеи по поводу подобного ресурса. Идея еще сыра и нужно узнать и оценить разные варианты. Если есть какие-то дополнительные идеи/мысли/предложения — пишите.
Путь первый — просветительская работа среди разработчиков использующих надстройки над языком с целью объяснить им идеи JS и как этот язык правильно использовать. Правильно используя язык весь код становится красивым.
Выход второй — совершенствование самих надстроек для генерации более качественного кода. В результате получим качественный код в приложениях (пусть даже и менее качественный чем идеальный код написаный вручную)
А вот дальше вы сосредоточились на первом пути. А ребята использующие .NET, насколько я понял, вместе со своим фреймворком пошли по второму пути и постепенно избавляются от страшненькой кодогенерации первых версий фреймворка. Не думаете же вы всерьез, что они были в восторге от ужасных значений id создаваемых раньше?
Вы идете к одной цели(красивому коду) разными путями. Вам нравиться JS и вы пишете красивый код на нем. Дотнетчикам нравится их фреймворк и они его используют, а создатели фреймворка постепенно приводят в чувства кодогенерацию. Вот собственно и все.
К слову, мне ближе позиция генерации кода и сейчас слежу вот за этим проектом: groups.google.com/group/ruby-red-js
Это перевод на русский язык подробного описания REST, начиная от причин возникновения и заканчивая реализацией в рельсах.
1) www.getafreelancer.com/projects/ASP-NET/ASP-NET-Progammer-Needed.html
2) Открываем Project Clarification Board
3) Вводим текст сообщения с адресом почты. Например, такой: «testing.email@testing.em»
4) Отправляем сообщение.
Получаем надпись «Error occured: You are not allowed to post contacts»
Ну а не наказывают за это скорее всего из-за разгильдяйства службы поддержки.
Детали платежей, настройки Тим, предоставляемый SVN и другие вкусности я постараюсь описать в следующей статье.
На мой взгляд, лучше всего было бы для каждого заказчика конфигурировать систему индивидуально. Все-таки вещи типа Ruby/Rails, Python и XSL нужны далеко не всем. Или, если не конфигурировать под каждого отдельную систему, то можно создать 20-30 разных вариантов настроек вместо 3-6 обычных.
Короче, гибкость вместо 'все включено'.
под ruby есть такое кол-во готовых прикладных библиотек, что пользователи уверены в том, что найдут то, что им нужно и часто ищут код
Если в ТЗ четко написано про адаптивную верстку, то верстальщику понадобятся все варианты раскладки, а не один.
4. Мы живем в неидеальном мире где пользователи могут допускать ошибки. Изображение этих ошибок тоже должно располагаться на странице и показать их можно очень по-разному. Как именно это сделать тоже должен думать дизайнер, а не верстальщик/программер/уборщица тетя Маша.