Сразу два новых рекорда было поставлено в минувший вторник. Рекордное количество мест (70 против предыдущих 40-50) было расхватано ровно за сутки (против 1.5 суток в прошлый раз). Вероятно, это объясняется темой, немного выходящей за рамки просто IT — «ИТ-бизнес». Помещение на 70 мест любезно предоставила фирма Helmes, за что ей большое спасибо.
Флагманом встречи был вопрос: «Стоит ли мне сидеть в моей компании и работать на дядю, получая X крон, если я могу сделать свою фирму и делая ту же работу, получать гораздо больше»?
Итак, что же мы узнали об ИТ-бизнесе?
Первый докладчик
Андрей Тукин — основатель онлайн-магазина OX.EE — рассказал о своём многогранном опыте занятия бизнесом начиная от работы в компании Софткей и заканчивая запуском монобрендового онлайн магазина DigiOutlet для стран Балтии, а также локальной версии проекта InSales — платформы для быстрого запуска онлайн-магазинов, разрабатываемой с использованиеем фреймворка Ruby on Rails.
* «Зачем заниматься бизнесом?»,
* «Стоит ли брать кредит под создание бизнеса?»
* «Как не залезть в долги?»
* «Нужно ли увольняться с работы?»
* «Стоит ли начинать свой бизнес во время кризиса?»
* «Как делить зарплату с партнёрами»
— вот далеко не полный перечень вопросов, которые Андрей поднял в своём докладе.
Вопросов из зала было много, а сколько их было после доклада!
Из запомнившегося
* «Надо бы чё-то замутить» (с чего начинается почти любой бизнес)
* Первый опыт почти всегда провальный
Между первой и второй
Марк Кофман вкратце рассказал о своей фирме Programeter и одноимённом продукте, который здорово вписался бы в концепцию сегодняшней встречи. Будем надеятся, что Programeter будет представлен полноценным докладом на следующей встрече.
Второй докладчик
Захар Кириллов поделился своим опытом организации ИТ-бизнеса. Он дополнил и углубил начатую тему, классифицировав стандартый набор граблей айтишника в бизнесе, разбив их (грабли) на категории, снабдив каждую рецептом и списком потенциальных подграблей и сдобрив хорошей порцией качественного ИТ-юмора.
Захар провёл очень интересную аналогию между ООП-программированием и бизнесом, а также между методологиями программирования (Waterfall, Agile и т.п.) и ведением бизнеса. По Захару, программисты, начиная свой бизнес, имеют определённое преимущестство, ибо они хорошо знакомы с этими методологиями и смогут легко применить их в бизнесе.
И конечно, пять баллов — это идеальная модель бизнеса по Захару: Cashflow + клиенты-наркоманы. Похоже, что это must-think для любого бизнесмена.
Из запомнившегося
* 100-налог=47
* «Посмотрел, как это делается в нашем государстве, и решил поставить на этом крест»
* «Клиенты-наркоманы покупают свой кусочек бинарного счастья»
* «3F: Friends, Family and Fools»
* «9 женщин не смогут родить ребёнка за 1 месяц»
* «Все CRM — гавно»
Третий докладчик
Ярослав Калищук сделал небольшой hands-on по Ruby on Rails — весьма популярной технологии, которая позиционируется как платформа, позволяющая легко и быстро создавать веб-приложения, а значит, могущая помочь в открытии своего бизнеса.
Ярослав за считанные 40 минут на наших глазах сделал мини-интернет-магазин и немножко юнит-тестов к нему.
Лично я за это время понял концепцию Ruby on Rails, в чём он хорош и для каких задач он подходит. То есть получил именно то, что ожидал. Спасибо!
Из запомнившегося
* «если бы не рельсы, я бы никогда не стал заниматься вэбом»
* «винда для девелопмента — отстой»
Благодарности:
* Helmes — помещение,
* Юра Муленко — организация, морс/кофе/печеньки
* Кирилл Линник — за домашнее задание, вопросы, призы и пиво
* Особоая благодарность всем участникам за своевременное прибытие на место — это действительно достижение!
PS. Результаты ДЗ от Кирилла
Только тро человек справились с домашним заданием по базам данных: Олег Чернецов (Webmedia), Антон Литвиненко (Programeter) и Сергей Мудрецов (Skype). Все их решения найдете в комментариях с постом самого задания. Самый оптимальный по скорости запрос был выбран благодаря MySQL и оглашен очаровательной девушкой, из рук которой Олег Чернецов и получил приз — игрушечную трехмерную модель базы данных. Спасибо всем, кто принял участие в этом задании.
PPS. Отзывы
Товарищи зрители, убедительная просьба любые свои комментарии и предложения по организации написать в комменариях к этому или следющим постам.
Также пожалуйста, оставьте в комментариях свои отзывы о докладчиках (принимается всё: критика, хвальба, пожелания). Они тоже люди, им нужна обратная связь! Если хотите сделать это анонимно, шлите их на мой адрес аndrеi дот solntsеv собако gмаil дот cоm
До следующей встречи! Следите за анонсами на DevClub.eu
MarkK
meetup super! osobenno zapomnilas formula Zahara "business model = cash + klienty/narkomany"
Mark
Ilja
Ярослав: Винда для девелопинга — сакс
Юрик: но-но-но!!!
🙂
Мне эта встреча осень сильно понравилась, все три доклада были великолепными и интересными для меня, за что авторам огромное спасибо!
Нда, вопрос о количестве народа на собраниях вскоре станет очень актуальным в ближайшее время… Надо будет что-то придумать.
Артём Курапов
Понравилось что Ярослав про руби основы рассказывал. Не думаю что с плагинами это было бы лучше — важно видеть как оно внутри сначала запускается. Хотелось бы продолжения
Ну и формула 100-налог=47 тоже понравилась
Anton Arhipov
стоило бы сделать встречу где рассмотрели бы Ruby-on-Rails и Django более подробно и детально, благо специалисты есть
Oleg Kuznetsov
Первый раз дошёл на встречу и не капли не пожалел, по сравнению с Mobile Monday было намного интереснее и много полезного узнал 🙂 В следущий раз обезательно приду 🙂
Setor
Отличная встреча!
Не написав ни строчки кода на ROR я понял, что где-то я всё это уже видел… PHP Symfony fw — если не клон, то во многом по концепции схож с Ruby on Rails (я сравниваю лишь реализацию MVC, в остальном PHP топчется в сторонке).
Было бы отлично на следующих встречах увидеть в действии Python & Django.
Так же хотелось добавить, я каждый день сталкиваюсь с какими-то нетривиальными задачами (WEB, PHP): мега-сложные формы с нетривиальными схемами валидации, использующие далеко не одну модель. На каждом шагу мультиязычные данные, причём, для разных языков/стран одни и те же предложения могут меняться местами, а в предложения подставляются различные переменные (в стандартных средствах для работы с i18n многое изначально не поддерживается). Постоянно приходится реализовывать различные "частные случаи" (Фаулер). Но стоит посмотреть демку или послушать доклад о WEB-фреймворках на других языках — у всех всё идеально, 1 модель — 1 форма, автоматическая валидация данных, никаких лишних условий… вот не верю! WEB-программисты, откликнитесь, сталкиваетесь вы с подобными проблемами, или у вас всё делается легко и просто без танцев с бубном?
Anton Arhipov
Setor, +100!
а ты можешь такой доклад сделать, о проблемах с навороченными формами? или обзор проблем с PHP?
з.ы. RoR вроде как на CakePHP похож, не находишь?
Juri Mulenko
@setor
+ 1 к проблемам и демкам.
Что касается мега сложныйх форм то тут помогают 2 вещи — упрощение форм(а ля визард) или разбитие форм на компоненты, каждая из которых имеет соотв. модель, валидацию полей и бизнесправил и т.д.
Anton Arhipov
Юра, +1. Если форма сложная надо сделать её простой 🙂 классный подход 🙂
Setor
> а ты можешь такой доклад сделать, о проблемах с навороченными формами? или обзор проблем с PHP?
@Антон
Доклад сделать могу, но я ещё сам не готов. Проблема, а главного — красивого решения пока нет. Мне кажется, я уже близко к нему. Бедным PHP программистам приходится через всё проходить самим через многоэтажные велосипеды.
> Что касается мега сложныйх форм то тут помогают 2 вещи — упрощение форм(а ля визард) или разбитие форм на компоненты, каждая из которых имеет соотв. модель, валидацию полей и бизнесправил и т.д.
@Юра
Упрощение чего-лио всегда даёт отличные результаты. Но клиент часто хочет всё засунуть на одну страницу в огромную форму, которая могла бы управлять шатлом. Иногда даже доходит до того, что значения полей в одной большой форме начинают конфликтовать между собой, когда изменение одного значения приводит к автоматическому изменению другого.
Пару месяцев назад на встрече о Java Web фреймворках рассказывалось о подобных формах (1 страница 1 форма) и якобы всё у них замечательно живёт, да ещё и сохраняется история на протяжении всего сеанса.
В формах меня больше всего волнует их динамическое содержимое(во всех демках и мануалах говорится только о статических формах, мне же часто приходится сталкиваться с динамическими наборами однотипных данных). Между запросами состояние базы может меняться, форму приходится сериализовать и сохранять между запросами, чтобы не потерять её исходное состояние. Иногда доходит до версионного контроля записей в таблице, для случаев, когда человек может работать с данными, которые кто-то в промежутке его работы изменил. О проблемах с формами можно говорить очень долго, но надо дать хорошие решения на злободневные проблемы.
> з.ы. RoR вроде как на CakePHP похож, не находишь?
Cake — пережиток PHP4. В последних версиях они наконец-то обновились до 5ки, но больш-во классов всё равно написаны в стиле 4й версии. Может для совместимости оставили… Так что кроме названия, лестных отзывов мне о нём ничего не известно, только то, что сам видел в исходниках. С symfony же приходится общаться очень тесно и её сходство с RoR налицо. "V" составляющая из "MVC" скопирована практически 1 в 1. "C" имеет много схожего, особенно в том, что касается "V". "M" можно и не сравнивать 🙂 М реализована на Propel/Doctrine на выбор программиста.
Так же в симфони используются похожие кодогенераторы и yaml'формат конфиг-файлов. Есть скаффолдинг.
Мне в презентации о RoR очень понравился деплой базы, в sf такого к сожалению нет. Немного настораживает обилие "магии", но я думаю, там всё кастомизируется под любые нужды.
И вопрос немного не по теме, как обычно в серьёзных WEB-приложениях используются транзакции? Например, в RoR? 1 длинная транзакция на один запрос (PHP к сожалению или к счастью живёт только в течение 1 запроса) или AUTOCOMMIT=0 и когда надо делать коммиты. Бывают случаи, когда приложение может упасть, а транзакцию надо кровь из носа закоммитить… Причём, не желательно коммитить то, что отработало лишь частично. Или в транзакции оборачиваются только важные изменения? Но использование такой схемы иногда вклинивает открытие новой транзакции в момент, когда открыта другая, что частично коммитит открытую, а это есть в корне неправильно.
Anton Arhipov
Setor, полюбому было бы классно о граблях с формами народу поведать в более развёрнутом докладе. Даже если у тебя решения нет сейчас, может быть у кого то из толпы появится идея — к нам сейчас приходит больше людей, чем эти комменты читает…
про транзакции в RoR я не в курсе, может ответит может другой (вобщем то, имхо, рельсы не подразумевают серьёзных веб-приложений :)). А в Java полно разных методик управления транзакциями, и на мой взгляд они не зависят от того, работаем мы с веб-приложением или просто с батчем. Можно насадить аспекты через AspectJ, а можно тупо самому коммитить… это довольно обширная тема.
Если говорить уж о совсем серьёзных приложениях, то например у Ebay вообще транзакций нет.
Kirill Linnik
2Sector
если разговор идет об Aranea, то да, там таких проблем нет. все сохраняется в сессии, потом, например, через паттерн observed-observable можно менять значения в исходной форме, если клиент куда-то ушел и сделал что-то, что меняет эти данные. в сложных формах нет никаких конфликтов между блоками, так как каждый блок — отдельный компонент, да и concurrent modification тоже поддерживается 🙂 все, на что наступают пхпшники, в яве решено уже как несколько лет.
slacker
cake php vs rails
вообще-то это кейк слизал, что мог с рельсов 🙂
>> сложные формы
я проблем с работой сложных форм не видел 🙂 валидация пишется елементарно. точно уверен, что можно построить красивое и элегантное решение
>>транзакции
есть в рельсах транзакции. в последних рельсах даже появились вложенные транзакции.
>>(вобщем то, имхо, рельсы не подразумевают серьёзных веб-приложений :))
мнда. как об стенку горох. ну откуда такое предубеждение? если все делается легко и непринужденно, почему обязательно должно быть плохо? зачем искать изяны? 🙂
slacker
правлю сам себя…
"зачем искать изяны?"
я имел ввиду, что на самом деле рельсы крутая штука. и пытаюсь донести до общественности, что вместо того, чтоб делать голословные заявления лучше самому попробовать разобраться в вопросе 🙂
Anton Arhipov
slacker,
не хотел задеть ничьи чувства 🙂
здеть "серьёзность" наверное не самое правильное слово. у меня например вопрос, могут ли рельсы выдержать большие нагрузки в рамках транзакционного бизнес-приложения а-ля интернет-банк. Здесь даже не в рельсах дело, а в самом ruby. Но для того чтоб это понять надо на рельсах hanza.net написать.
Прошу понять меня правильно, это не холивар.
То есть рельсы для веб приложений это СУПЕР, особенно когда у тебя не оракл со старинной структурой под этим приложением. По крайней мере так кажется на первый взгляд. Может чере пару недель я познаю rails-fu и мнение будет совершенно другим 🙂
slacker
>>могут ли рельсы выдержать большие нагрузки в рамках транзакционного бизнес-приложения а-ля интернет-банк.
рельсы отлично скейлятся. архитектура такова, что апп-серваки не имеют состояния. данные хранятся либо в ДБ либо в мемкешед каком-нить. в следствие этого ставим лоад-балансер и имеем практически линейное скалирование 🙂
Anton Arhipov
slacker,
это суппер. даёшь доклад на эту тему 🙂
slacker
а что там рассказывать? халява 🙂
я могу рассказать про любимую фичу рельсов — ActiveRecord. Это ORM-mapper. Он офигенен 🙂
Anton Arhipov
slacker,
халява халявой.. про ActiveRecord я например в курсе…
интерес для перезентации представлет на самом деле не крутость технологии, а те крутые грабли или проблемы которые эта технология позволила тебе решить за то время что тебе посчастливилось использовать эту технологию.
( а ведь действительно посчастливилось 🙂 я даже завидую чуток 🙂 )
Ph
Эх, опаздал я с комментариями, все сказали уже 🙂
…а в переписке hanza.net на рельсах я бы с удовольствием поучавствовал 😉
Мои две копейки:
Рельсы не помогут решить проблему "что делать?", но как только проблема "что делать?" решена, с тем "как делать" проблем не возникает. Можно делать все за минуты. Я к тому, что веб-девелопмент это не только "базы данных" и "валидации". Можно потратить месяцы на передвижения двух пикселей в цсс, на всякий юзабилити и переставления местами элементов форм, от этого рельсы как таковые не спасают (хотя и с этой перспективы там есть свои подспорья).
Язык Руби ощущается очень современным, он интуитивно понятен, там чудесный синтаксис и исчерпывающая стандартная библиотека. Субьективно самый приятный язык для написания скриптов вообще. После Руби программировать под веб на ПХП — почти как на ассемблере (можно, но не целесообразно) 🙂 Я боюсь представить что там с другими языками.
Фреймворк "Рельсы" это, опять же субьективно, коллекция всех самых прогрессивных тенденций, что есть в вебдеве на сегодняшний момент. Там есть все что нужно. Счастлив тот человек, кто упрется в ограничения рельсовой архитектуры или в проблемы скалирования. В любом случае активный комунити все агрессивно фиксит:)
На вскидку о некоторых преимуществах/удобно решаемых проблемах.
— Удобство. все очень удобно, адекватно и на своих местах. Весь код лежит на своих местах, очень легко перенять и продолжить работу другого человека.
— Скорость. подавляющее большинство стандартных концепций уже реализованы во фреймворке.
— Удобная i18n out of the box с возможностью подключать различные бэкэнды по-вкусу.
— Тоже саме с кэшированием.
— Удобная валидация данных.
— Ruby решает 😉
— ActiveRecord прекрасен. Чудесный интерфейс к БД.
— Meta-html язык написания шаблонов HAML/SASS. Никаких больше случайно незакрытых тегов в десятом вложенном шаблоне, которые не найти.
— Прозрачные транзакции, в том числе и вложенные.
— REST.
— Реагирует на формат обращения в контексте одного пути. Можно определить что /index.xml будет отдавать вам данные в xml, а /index.js в JSON. Удобно вяжется с AJAXом.
— Есть плагин с удобным интерфейсом к Sphinx.
— Встроенный "mod_rewrite", можно легко описывать пути любой сложности.
— Вербозность. Баги не приходится долго искать.
slacker
"…а в переписке hanza.net на рельсах я бы с удовольствием поучавствовал ;)"
ага. и старый дизайн вернуть 🙂
Anton Arhipov
хо. чёт затянулось
опять же. мне нравится руби, но у любого энтузиазма должен быть скепсис.
вот посмотрите на досуге, M. Fowler рассказывает как Thhoughworks всё получилось
http://www.infoq.com/presentations/fowler-ruby
"We deliver slow solutions to our clients but they don't mind". Если кто использовал mingle (один из продуктов от TW), наверное могут высказать своё мнение в этом плане.
линейная скалируемость системы говорите?
Andrei Filimonov
Посмотрел.
Ну и откуда взялся скепсис? Хорошо ж дядька рассказывает, слушайте внимательнее 😉
Нада смотреть правде в глаза. Он там хорошо говорит про трейдофы в разработке. В 80% проектов ботлнеки не в скорости языка. Большинство веб-приложений нашей реальности довольно статичны и отлично, я подозреваю, кешируются.
Добавлю что на подходе значительно облегченный RoR 3.0, и значительно ускоренный Руби 1.9.
But i digress.
Juri Mulenko
Больше всего в РОРе мне понравилась
1)скорость разработки. Помнится Ярик мне показывал почти готовый проект в которм было не более 2к строчек кода. Впечатлён. Время-деньги и тут мы явно экономим.
2)Миграции. Весчь.
3)Ориентированность на тестирование.
Не понравилось
1)наверное слишком жесткая привязка к ActiveRecord(да и вообщение продвижение идеи, что Модель — это слепок данных с прикрученной валидацией). В проектах средней руки, когда доменная модель легко переносится на БД это существенно облегчает жизнь. Но крайне бы не советовал этот паттерн при разработке систем со сложной бизнес-логикой.
2)Отсутствие скринкастов по темам связанным с наследованием в ActiveRecord да и вообще с наследованием. Ленивый йа. "Я б в пожарники пошёл, пусть меня научат" 🙂
Anton Arhipov
вобщем тема имеет огромный потенциал! надо раскрывать 🙂
Oleg Kuznetsov
А видео с выступлений будет выложено!!!!!!
Anton Arhipov
Олег,
конечно же будет! как только оператор перестанет лениться то записи сразу же окажутся в блоге! 🙂
Дмитрий Жучков
> мега-сложные формы с
> нетривиальными схемами
> валидации, использующие
> далеко не одну модель
Это решается через виртуальные атрибуты, но надо писать свой код, обычными декларативными методами не получится.
> На каждом шагу мультиязычные
> данные, причём, для разных
> языков/стран одни и те же
> предложения могут меняться
> местами, а в предложения
> подставляются различные
> переменные
С некоторых пор проблемы с L10n в рельсах решены для хранения полей моделей на разных языках есть плагин globalize2
> у всех всё идеально, 1 модель
> — 1 форма, автоматическая
> валидация данных, никаких
> лишних условий… вот не верю!
Естественно частные случаи не покрываются ни в одном фреймворке. Задача любого фремворка это предоставить достаточное покрытие основных сценариев, а так же поддержать легкость кастомизации. Не возможно написать фреймворк который будет учитывать пожелания каждого. В добавок ограничения всегда стимулируют простые методы, и не дают бессмысленно раздувать интерфейс.
> Но клиент часто хочет всё
> засунуть на одну страницу
> в огромную форму, которая
> могла бы управлять шатлом.
А воспитывать клиентов не получается? Тогда сочувствую. недавно был инцидент, когда один чел наехал на сайт American Airlines — у них тоже любят сложные формы. Он предложил облегченный вариант, вы наверное в таком же положении как и дизайнер AA сайта который описал реальность.
> Наверное слишком жесткая
> привязка к ActiveRecord
> (да и вообщение продвижение
> идеи, что Модель — это слепок
> данных с прикрученной …
Вначале я тоже пытался бороться с фреймворком. Потом читал много кода, посмотрел как мои проблемы решают другие люди. Пересмотрел почти все скрикасты, после этого полегчало
> Отсутствие скринкастов по
> темам связанным с наследованием
> в ActiveRecord да и вообще с
> наследованием.
А для каких цедей нужно наследование? Может это не ruby way? На уровне моделей понятие полиморфизма вполне поддерживается. Если надо какой-то код между классами прошарить то можно всегда mixin сделать.
Большая проблема для рельсов — это legacy DB. Одно дело если ты базу с нуля рисуешь, другое дело если что-то досталось по наследству. Схема у базы как правило не ложится в концепции ActiveRecord, и его использование становится не возможным. Поэтому будет нужна миграция. В случае большого объема данных — это самоубийство.
Прошу прощения за длинный коммент, не было времени написать коротко.
ALeX inSide
Фотки со встречи:
* http://anton-arhipov.livejournal.com/60738.html
* http://alex-inside.livejournal.com/641402.html
Почитал комменты, и в общем-то вижу что как и любая новая относительно радикальная технология (RoR) вызывает желание похоливорить.
Для меня проблема RoR — это сложность legacy поддержки старой БД сайта и тем более апгрейда сайта — переписывать занова придётся. Да ещё и хостинг скорее всего другой и более дорогой придётся брать.
Это как с Джаваским Томкэтом — было сложно найти хостинг чтобы потестить live свои java-сервисы. Это сильно мешает распространению имхо.
Ну а если для работы, если клиент хочет, то можно всегда для него и не только на Ruby пописать =)
Ну, и как Ярик говорит, для себя проэкты я бы врят ли на Ruby писал =)
Но Руби мне понравился. Хотелось бы ещё продолжение, а так же подобную сессию программинга на Python.
Anton Arhipov
Если я не ошибаюсь PureMVC для ruby позволяет отвязаться от ActiveRecord и тем самым работать так же удобно с legacy базами. Так что счастье с ruby может быть и без ActiveRecord-a 🙂
slacker
>> Ну, и как Ярик говорит, для себя проэкты я бы врят ли на Ruby писал =)
Это когда я такое говорил? 🙂 Для себя я бы писал скорее всего только на Рельсах.
>>Если я не ошибаюсь PureMVC для ruby позволяет отвязаться от ActiveRecord и тем самым работать так же удобно с legacy базами. Так что счастье с ruby может быть и без ActiveRecord-a 🙂
использование рельсов вовсе не обязует использовать АктивРекорд.
омг, Антон, что за нелюбовь к ОРМ-мапперам? 🙂
Anton Arhipov
slacker,
нелюбовь к ORM? на не сказал бы что уж так радикально. Но особой тяги к таким штукам не испытываю, это верно.
Я не говорю что ActiveRecord это плохо. Напротив — на работе используем его, и всё нормально. Я просто для веб-а не программирую, поэтому у меня может быть немного извращённый взгляд на вещи 🙂
slacker
а вы все фичи используете?
named_scope-ы?
различные связи и ассоциации?
полиморфик модели?
валидация?
before_save/after_save?
обзерверы?
Это первое что в голову пришло.
Anton Arhipov
slacker,
нет конечно. такие задачи стоят перед другими приложениями которые у нас пишут на Java, и соответственно для этих нужд используется Hibernate
ActiveRecord используется у нас довольно ограничено — тупо для заполнения базы данными для тестов, впринципе можно было бы и без него обойтись
slacker
советую хотяб "побаловаться" с ним. очень упрощает работу с ДБ.
Anton Arhipov
slacker.
в данный момент именно этим и занимаются 🙂
asolntsev
Гыц-гыц…
Когда вижу такие фразы про Руби: "на подходе значительно облегченный RoR 3.0, и значительно ускоренный Руби 1.9.", начинаю думать: значит, было что облегчасть и ускорять? Значит, не такой уж он и супер-пупер?…
Anton Arhipov
asolncev
ну на подходе так же и Java 7 🙂 никто не совершенен :))
Andrei Filimonov
"значит, было что облегчать и ускорять?" != "Значит, не такой уж он и супер-пупер?…".
Охх 🙂
В кратце поясню: стандартный дистрибутив рельс поставляется с кучей всяких фишек, от веб-сервера до привязанного яваскрипт фреймворка, что безусловно удобно для нубской разработки, но бесполезно для продвинутой. Это было принято во внимание, и сейчас ведется работа над дополнительной модуляризацией фреймворка. Как я понимаю в РоР 3.0 можно будет набрать себе только необходимых компонент и не тащить за собой вагон того, чем не воспользуешься.
Так и в Руби. Автор руби был в большей степени заинтересован в качестве самого языка, чем в скорости его интерпретатора (что очень правильно, на мой взгляд). А теперь можно и по-оптимизировать;)
да и вообще;)
Anton Arhipov
баян 🙂
slacker
не совсем так конечно. и сейчас можно спокойно отключить в конфигурации не нужные тебе компоненты.
на руби было 2 фреймворка-конкурента. Рельсы и Мерб. разработчики решили, что лучше обьединить усилия и обьединились. Рельсы 3.0 будет фреймворк включающий в себя лучшее из 2ух.
ПС. мы как-то с другом обсуждали когда-то (когда рельсы 2.0 только вышли), что рельсы на столько круты, что хз чего ещё там можно улучшить.
Andrei Filimonov
Можно отключить, но…
RJS сейчас завязан на prototyepe например, и его не отключить. В то время как jQuery — очевидный выбор. В 3.0 это пофиксят.
slacker
Можно заюзать плагин и будет тебе джейкваери. Но тут такая тема: для простых вещей и прототайпа хватит, а для сложных тебе RJS не нужен.
Andrei Filimonov
Вцелом да.
Dmitri Semirenko
Господа! Пните уже там кого следует, чтобы видео появилось побыстрее!!
Пропустил к сожалению эту встречу.. охота хотя б видео поглядеть.
Kirill Linnik
сегодня принеприменнейше пнем 🙂
Ilja
Пора форум ставить 🙂