Future
DAddYE
I want to propose a little refactoring of merb.
Now at the first view Merb for new guys same to be a little
complicated and with a lot lot lot lot gems, I like so much gems, but
20+ gems when I do a fresh install of merb is a little strange.
Im very interested in using merb sponsor it. As I say through pm with
the merb staff my society have a big experience with ruby framework
and personally I made some like 100+ websites/webapps.
So, for me is necessary focus to some points:
1) Make merb more coincise (was born with some django philosophy...
but now?)
2) Make merb a little smaller (in terms of gems)
3) Make merb more stable but revolutionary
1) More Coincise:
Now in merb for do one thing we have a lot of way for do that, I love
extensibility but for me I necessary (at the moment) have a one/two
way for do a thing, then if a developper want can easily extend it.
Some examples of question of friends that tell me:
Why merb-gen stack / core ?
Why merb-gen flat / very flat ?
Why we can't simply have merb-gen app and merb-gen tiny-app ? Two
coincise way ... and a developper can easly extend it.
Why we have gems for merb-actions-args? Why is not in the core?
For example personally I forgotten that merb-action-args is
incompatible with ruby 1.9, so why confuse a lot of us (not all) with
them?
Why merb-params-protections? Why is not in the core? At the moment I
don't remember the answer
2) Make merb a little smaller (in terms of gems):
Now we have a gem for everything. merb-exceptions (that I love) merb-
assets merb-actions-args merb-slices etc...
My pruppose is:
- drop merb-actions-args
- merge with core merb-params-protections or drop it if not possible
- merge merb-assets with merb-helpers
- separate (at the moment) merb-exceptions
- drop merb-slices (I will explain why)
There also another reason in this way the merb team can focus to
important things for people that use merb for big apps **productions**
envs.
3) Make merb more stable but revolutionary
As I say now (for me) is the moment to focus for use merb in
production. A slogan is necessary few things that work well!
Then, is time to give some thing new to the ruby scene, as Sinatra do.
Merb now can't be a "mirror" of rails but a new framework.
For example, merb-slices, some love it some don't love it, personally
I hate it, not because I don't apreciate it but because I very very
very complicated read the code written from antother person. Slices
like rails-engines are not linear. Why we can "duplicate" a thing that
just exist and we don't try to create a new way?
I love one thing of django, the multiapp support.
I dream but for me a thing like that will be beautiful:
$ merb-gen project store
$ cd store
$ merb-gen app core
$ merb-gen app frontend-ecommerce-1
$ merb-gen app frontend-ecommerce-2
$ merb-gen app frontend-ecommerce-3
Then our dir can be like this: http://gist.github.com/225365
We can also made a routing like sinatra + sinatra-map that can be
"innovative"
Other things in my opinion is very important to discuss:
- Add a I18n (for example 30% of our sites use it)
- Use DM as default? There are big big project (like twitter) that use
it? Is stable?
At the end for me is necessary big refactoring so all of us can focus
to the **very important things** and use check test stress the "core"
services of merb.
DAddYE
Nicholas Orr
DAddYE
> If you want less options go with Rails.
fatures than merb? That's incredible...
> If you want tiny go with Sinatra or merb-gen very-flat
> Pick the tool for the job - Merb works great as is.
> Has a lot of functionality and flexibility.
> Merb can be molded and manipulated to do what you want to do.
links?
> I refuse to use Merb via gem install merb as you get a crap load of gems (as
> you have pointed out) and so use the bundler :)
a vps, but think people like me that for each server host some like
150+ sites... I can bundle gems in a vendor dir? So in future if there
is a "security problem in merb" I need to edit 150+ projects and then
git push it on the server... we are crazy?
I want (if possible) that all of us can take a GLOBAL view, don't see
only your reality but think to:
- Newbie people
- Big society
- You
Then, about the dead of merb, I talked with some member of the current
team of merb and I don't think It will die.
Chris McCauley
> Hi guys,
>
> I want to propose a little refactoring of merb.
>
> Now at the first view Merb for new guys same to be a little
> complicated and with a lot lot lot lot gems, I like so much gems, but
> 20+ gems when I do a fresh install of merb is a little strange.
>
Hmm, I have one (core). That runs a pretty complex rules engine. Not
sure why you would /need/ 20.
> Im very interested in using merb sponsor it. As I say through pm with
> the merb staff my society have a big experience with ruby framework
> and personally I made some like 100+ websites/webapps.
>
> So, for me is necessary focus to some points:
>
> 1) Make merb more coincise (was born with some django philosophy...
> but now?)
If you mean more concise by having more gems then I think you may
benefit from taking a look at how many of those gems you need. For me
merb is as concise as I need.
> 2) Make merb a little smaller (in terms of gems)
Smaller than one ;-)
> 3) Make merb more stable but revolutionary
>
Haven't had any stability issues and we use it in production across a
cluster.
> 1) More Coincise:
>
> Now in merb for do one thing we have a lot of way for do that, I love
> extensibility but for me I necessary (at the moment) have a one/two
> way for do a thing, then if a developper want can easily extend it.
>
> Some examples of question of friends that tell me:
>
> Why merb-gen stack / core ?
> Why merb-gen flat / very flat ?
>
We originally used merb-gen to generate a very flat layout but you're
right, it isn't needed as 'very flat' can be done by hand.
> Why we can't simply have merb-gen app and merb-gen tiny-app ? Two
> coincise way ... and a developper can easly extend it.
>
Don't disagree other than to say how does having the other options get
in your way? Having the very-flat option helped bootstrap our use of
merb last year
> Why we have gems for merb-actions-args? Why is not in the core?
>
Never used it, not even sure what it is. Probably that's a good argument
for not having it in the core.
> For example personally I forgotten that merb-action-args is
> incompatible with ruby 1.9, so why confuse a lot of us (not all) with
> them?
>
Thanks, didn't know that but doesn't that argue against having it in the
core - our app seems to run fine with 1.9.1
> Why merb-params-protections? Why is not in the core? At the moment I
> don't remember the answer
>
Again, we have a perfectly good use-case - we have production apps not
using it and I'm sure we wouldn't be alone.
> 2) Make merb a little smaller (in terms of gems):
>
One of your points above seem to argue against this. Also wouldn't more
optional gems when brought into core potentially reduce stability?
> 3) Make merb more stable but revolutionary
>
> As I say now (for me) is the moment to focus for use merb in
> production. A slogan is necessary few things that work well!
>
We're in production for a year now without problems and our use of Merb
is only growing!
> Then, is time to give some thing new to the ruby scene, as Sinatra do.
>
> Merb now can't be a "mirror" of rails but a new framework.
>
> For example, merb-slices, some love it some don't love it, personally
> I hate it, not because I don't apreciate it but because I very very
> very complicated read the code written from antother person. Slices
> like rails-engines are not linear. Why we can "duplicate" a thing that
> just exist and we don't try to create a new way?
>
> I love one thing of django, the multiapp support.
>
> I dream but for me a thing like that will be beautiful:
>
> $ merb-gen project store
> $ cd store
> $ merb-gen app core
> $ merb-gen app frontend-ecommerce-1
> $ merb-gen app frontend-ecommerce-2
> $ merb-gen app frontend-ecommerce-3
>
> Then our dir can be like this: http://gist.github.com/225365
>
> We can also made a routing like sinatra + sinatra-map that can be
> "innovative"
>
> Other things in my opinion is very important to discuss:
>
> - Add a I18n (for example 30% of our sites use it)
We use unicode and unicode-chars.
> - Use DM as default? There are big big project (like twitter) that use
> it? Is stable?
>
We don't use an orm at all. Love the fact that we don't need to bloat
the core with this.
>
> At the end for me is necessary big refactoring so all of us can focus
> to the **very important things** and use check test stress the "core"
> services of merb.
We're pretty happy with the core. I wouldn't be keen to have a big
increase in this. Remember "no code has fewer bugs than no code"
Chris
Nicholas Orr
>
> > Are you aware that Rails 3.0 supersedes Merb.
> > If you want less options go with Rails.
>
> You are convinced about that? So in your opinion Rails has less
> fatures than merb? That's incredible...
no... merb is flexible, rails is rigid in that there is a golden path.
Moving off it, is possible, however doing that in rails has more to
think about than merb. The goal of rails 3.0, as I understand it, is
to provide the golden path at the same time be whole lot simpler to
make ones own golden path.
> > If you want tiny go with Sinatra or merb-gen very-flat
>
> Where I say that? I say only: more concise, more stable, more tiny.
>
> > Pick the tool for the job - Merb works great as is.
> > Has a lot of functionality and flexibility.
> > Merb can be molded and manipulated to do what you want to do.
>
> Tell me, how many webapps do you build with them can you show me some
> links?
http://www.1300calculators.com.au is built on MagnitudeCMS.com - which
is what I'm using to build all content "type" websites going forward.
This week / next week I'm moving http://www.pdfa.com.au to MCMS. MCMS
is my version of Joomla built on Merb / CouchDB.
I've built an insurance quoting tool with merb (couchdb/mysql) that is
in production, it is back office tool (as such not something I can
share with the net at large).
The calculator on the 1300calculator sites above has a merb version
(the one on that site is backed by sinatra) that 45 brokers use daily
to generate car finance quotes.
> > I refuse to use Merb via gem install merb as you get a crap load of gems (as
> > you have pointed out) and so use the bundler :)
>
> Do you use some thing in a production env? I don't mean ONE "site" on
> a vps, but think people like me that for each server host some like
> 150+ sites... I can bundle gems in a vendor dir? So in future if there
> is a "security problem in merb" I need to edit 150+ projects and then
> git push it on the server... we are crazy?
Yeah that would be pretty crazy. At the same time, if a feature comes
into merb that breaks every single one of your 150+ apps do you want
your current app that is being developed to not be able to take
advantage of this new feature?
It's all about pros/cons and choosing a path that fits your goals / needs.
For me, bundler equlas my app works regardless of the system gems. In
fact I've made my production environment ruby 1.8.7 + rubygems 1.3.5 +
bundler + rake - everything else needs to be inside the app dir.
I'm not a hosting provider (Engine Yard Solo / Heroku), ZN either
looks after everything or the client looks after everything (including
hosting/running). Hence why I'm bothering with MCMS, setting up a
Joomla site once is great, doing it 20+ times is a real damn pain in
the ass!
> I want (if possible) that all of us can take a GLOBAL view, don't see
> only your reality but think to:
>
> - Newbie people
> - Big society
> - You
Well at the end of the day each person figures out what is best for
themselves, if they have a need to service 1000s of clients / apps and
want to manage an infrastructure efficiently, they'll figure out a way
and hopefully share their experience.
For me my goals are pretty specific - build content websites that run
on MCMS so I have minimum moving parts. I neither have the time nor
the skills required to build Basecamp/Highrise/GitHub type
applications on my own...
I was a newbie to rails, then I found merb (0.6) and got off and
running, now I get ruby, and switch between sintra & merb. I'm self
taught, the only thing I had going for me when I hit ruby was a
foundation in OO via Java.
From what I can tell you're looking for a way to manage 150+ apps that
are built on merb - imo that task is just plain "not" simple... Maybe
merb isn't the tool for you? Maybe it is and you're in a unique
situation to be able to figure it out and provide patches to allow
merb to thrive in such a situation.
> Then, about the dead of merb, I talked with some member of the current
> team of merb and I don't think It will die.
I don't think merb will die either. it has its place and use.
Nick
Davide D'Agostino
On Tue, 2009-11-03 at 11:50 -0800, DAddYE wrote:Hi guys,I want to propose a little refactoring of merb.Now at the first view Merb for new guys same to be a littlecomplicated and with a lot lot lot lot gems, I like so much gems, but20+ gems when I do a fresh install of merb is a little strange.
Hmm, I have one (core). That runs a pretty complex rules engine. Not
sure why you would /need/ 20.
Im very interested in using merb sponsor it. As I say through pm withthe merb staff my society have a big experience with ruby frameworkand personally I made some like 100+ websites/webapps.So, for me is necessary focus to some points:1) Make merb more coincise (was born with some django philosophy...but now?)
If you mean more concise by having more gems then I think you may
benefit from taking a look at how many of those gems you need. For me
merb is as concise as I need.
2) Make merb a little smaller (in terms of gems)
Smaller than one ;-)
3) Make merb more stable but revolutionary
Haven't had any stability issues and we use it in production across a
cluster.
1) More Coincise:Now in merb for do one thing we have a lot of way for do that, I loveextensibility but for me I necessary (at the moment) have a one/twoway for do a thing, then if a developper want can easily extend it.Some examples of question of friends that tell me:Why merb-gen stack / core ?Why merb-gen flat / very flat ?
We originally used merb-gen to generate a very flat layout but you're
right, it isn't needed as 'very flat' can be done by hand.Why we can't simply have merb-gen app and merb-gen tiny-app ? Twocoincise way ... and a developper can easly extend it.
Don't disagree other than to say how does having the other options get
in your way? Having the very-flat option helped bootstrap our use of
merb last year
Why we have gems for merb-actions-args? Why is not in the core?
Never used it, not even sure what it is. Probably that's a good argument
for not having it in the core.
For example personally I forgotten that merb-action-args isincompatible with ruby 1.9, so why confuse a lot of us (not all) withthem?
Thanks, didn't know that but doesn't that argue against having it in the
core - our app seems to run fine with 1.9.1
Why merb-params-protections? Why is not in the core? At the moment Idon't remember the answer
Again, we have a perfectly good use-case - we have production apps not
using it and I'm sure we wouldn't be alone.
2) Make merb a little smaller (in terms of gems):
One of your points above seem to argue against this. Also wouldn't more
optional gems when brought into core potentially reduce stability?
3) Make merb more stable but revolutionaryAs I say now (for me) is the moment to focus for use merb inproduction. A slogan is necessary few things that work well!
We're in production for a year now without problems and our use of Merb
is only growing!
Then, is time to give some thing new to the ruby scene, as Sinatra do.Merb now can't be a "mirror" of rails but a new framework.For example, merb-slices, some love it some don't love it, personallyI hate it, not because I don't apreciate it but because I very veryvery complicated read the code written from antother person. Sliceslike rails-engines are not linear. Why we can "duplicate" a thing thatjust exist and we don't try to create a new way?I love one thing of django, the multiapp support.I dream but for me a thing like that will be beautiful:$ merb-gen project store$ cd store$ merb-gen app core$ merb-gen app frontend-ecommerce-1$ merb-gen app frontend-ecommerce-2$ merb-gen app frontend-ecommerce-3Then our dir can be like this: http://gist.github.com/225365We can also made a routing like sinatra + sinatra-map that can be"innovative"Other things in my opinion is very important to discuss:
- Add a I18n (for example 30% of our sites use it)
We use unicode and unicode-chars.
- Use DM as default? There are big big project (like twitter) that useit? Is stable?
We don't use an orm at all. Love the fact that we don't need to bloat
the core with this.
At the end for me is necessary big refactoring so all of us can focusto the **very important things** and use check test stress the "core"services of merb.
We're pretty happy with the core. I wouldn't be keen to have a big
increase in this. Remember "no code has fewer bugs than no code"
Chris
Davide D'Agostino
Then tell me what of thing that I say in your opinion was wrong?
I prefer a team that work on merb-slices, merb-action-args, merb-auth,
merb-param-protections, or you prefer a team that focus on the core
(including helpers assets mailer etc...) ?
Also, you prefer a builtin I18n or prefer a merb-auth?
Also, you prefer a slice or a complete multiapp?
In your case you "love" mcms right?
With my example you can have in your path some like:
/mymcs/core
/mymcs/hirepurchasecalculator
/mymcs/platinumdirectfinanceaustralia
/mymcs/autotest
/mymcs/config
/mymcs/gems
Chris McCauley
A few corrections / clarifications below ...
On Wed, 2009-11-04 at 12:44 +0100, Davide D'Agostino wrote:
> > On Tue, 2009-11-03 at 11:50 -0800, DAddYE wrote:
> >
> > If you mean more concise by having more gems then I think you may
> > benefit from taking a look at how many of those gems you need. For
> > me
> > merb is as concise as I need.
> >
>
>
> As you say below there are some aspects that are not clean:
> - merb-actions-args
> - merb-params-protections
>
I didn't say they weren't clean, I said I didn't know what they were
because we've never needed them. We only have merb-core installed and
that works great for us.
> >
> What is your thought about above?
>
> > > - Add a I18n (for example 30% of our sites use it)
> >
> > We use unicode and unicode-chars.
> >
>
>
> Yea but if you have a I18n site, how do u manage translation or
> localization of time/time zone?
>
Fair point, we only need to take process data from different locales,
not to provide a localised interface.
> > > - Use DM as default? There are big big project (like twitter) that
> > > use
> > > it? Is stable?
> > >
> >
> > We don't use an orm at all. Love the fact that we don't need to
> > bloat
> > the core with this.
> >
>
>
> Yea, for me is the time to ship a framework with a non orm engine like
> datamapper or your couchdb
>
>
> I think also is the time to ship a framework with HAML instead old
> erb.
>
None of these belong in core though.
>
> >
> >
> >
> > Chris
> >
Davide D'Agostino
Chris
Nicholas Orr
<d.dag...@lipsiasoft.com> wrote:
>
> Do you use extjs? Great! Take a look on my project lipsiadmin.com
>
> Then tell me what of thing that I say in your opinion was wrong?
>
> I prefer a team that work on merb-slices, merb-action-args, merb-auth,
> merb-param-protections, or you prefer a team that focus on the core
> (including helpers assets mailer etc...) ?
>
> Also, you prefer a builtin I18n or prefer a merb-auth?
>
> Also, you prefer a slice or a complete multiapp?
>
> In your case you "love" mcms right?
>
> With my example you can have in your path some like:
>
> /mymcs/core
> /mymcs/hirepurchasecalculator
> /mymcs/platinumdirectfinanceaustralia
> /mymcs/autotest
> /mymcs/config
> /mymcs/gems
However from your example above..
Not sure how this helps. I mean if you look at 1300calculators.com.au
there are 12 domains involved (they look like 12 websites to google).
This is on purpose for SEO reasons. URLs have some weights when it
comes to SEO. I'm building content websites - not an application...
Pavel Kunc
I'm glad there went the public discussion and more voices speak than.
It's comforting. I'm not going to dig deep here because we prepare
official announcement of the 1.0.15 release which we did and some more
plans and also big update on the current situation.
To respond to Davide's post.
The main thing we try to do now is to fix as much bugs as we can and
bundle that work to 1.1.x releases. This is mainly making Merb more
stable. The heritage we have in lighthouse is not pretty and many
people posted patches or issues which was never dealt with. We try to
fix this and it is currently our priority.
I'm (and this is my own opinion) not too fond of merging current gems,
even dropping some is tricky due to backward compatibility. The merb
philosophy was and still is take what you want, leave what you don't
need. That's also the reason why merb has so many gems. One important
note is that merb is METAPACKAGE for merb-stack. I never ever used
that because I for example don't use the DataMapper. I also don't use
merb stack generators. With merb you should always choose what you
want to use and craft your own Gemfile accordingly. If you need to do
it many times, write your own generator for your app for example.
We thought hard what to drop (merb-action-args are fist candidate),
what to migrate etc... It's not actually easy and you piss off one
side or another :-) I'm more fond of dropping gems than merging. We
started to cut some of the gems out from the github.com/merb/merb repo
(all orms, merb-aut) and put it to separate repos. Also we dopped merb-
more and merb-plugins and moved supported gems to it's own repos.
That's are first steps.
I think that many things which are currently in the Merb especially
things which bothers Davide are from the age when merb core team tried
to compete with Rails and provide similar "newbie-out-of-box"
experience. So instead there is something you can change to your
needs, it is there is this or this or this You choose what you
want :-) I'm happy to move merb towards more hacker approach again.
Please give us some time, because we have a lot to do with the
migration and bugfixing. I don't suppose that the 1.1 will have any
new features. It's going to be just bugfixes, improvements. And even
after that we will probably do some more bugfixing (1.1.x) from the
lighthouse and maybe some new features in 1.2.
However for 1.2 we don't have plan what to include and I'm glad we
have debate like this. We definitely will send out to discuss what we
want to include in 1.2 so you all can influence it. I'm thinking of
more rack integration (sessions, test, middleware), maybe different,
faster router, i18n (make some of the solutions solid and officially
supported).
Pavel
On Nov 4, 9:45 pm, Nicholas Orr <nicholas....@zxgen.net> wrote:
> On Wed, Nov 4, 2009 at 11:24 PM, Davide D'Agostino
>
>
>
>
>
> <d.dagost...@lipsiasoft.com> wrote:
>
> > Do you use extjs? Great! Take a look on my project lipsiadmin.com
>
> > Then tell me what of thing that I say in your opinion was wrong?
>
> > I prefer a team that work on merb-slices, merb-action-args, merb-auth,
> > merb-param-protections, or you prefer a team that focus on the core
> > (including helpers assets mailer etc...) ?
>
> > Also, you prefer a builtin I18n or prefer a merb-auth?
>
> > Also, you prefer a slice or a complete multiapp?
>
> > In your case you "love" mcms right?
>
> > With my example you can have in your path some like:
>
> > /mymcs/core
> > /mymcs/hirepurchasecalculator
> > /mymcs/platinumdirectfinanceaustralia
> > /mymcs/autotest
> > /mymcs/config
> > /mymcs/gems
>
> I haven't looked at LipsiADMIN yet - will look more later today.
> However from your example above..
>
> Not sure how this helps. I mean if you look at 1300calculators.com.au
> there are 12 domains involved (they look like 12 websites to google).
> This is on purpose for SEO reasons. URLs have some weights when it
> comes to SEO. I'm building content websites - not an application...
>
>
>
>
>
>
> >>>> Are you aware that Rails 3.0 supersedes Merb.
> >>>> If you want less options go with Rails.
>
> >>> You are convinced about that? So in your opinion Rails has less
> >>> fatures than merb? That's incredible...
>
> >> no... merb is flexible, rails is rigid in that there is a golden path.
> >> Moving off it, is possible, however doing that in rails has more to
> >> think about than merb. The goal of rails 3.0, as I understand it, is
> >> to provide the golden path at the same time be whole lot simpler to
> >> make ones own golden path.
>
> >>>> If you want tiny go with Sinatra or merb-gen very-flat
>
> >>> Where I say that? I say only: more concise, more stable, more tiny.
>
> >>>> Pick the tool for the job - Merb works great as is.
> >>>> Has a lot of functionality and flexibility.
> >>>> Merb can be molded and manipulated to do what you want to do.
>
> >>> Tell me, how many webapps do you build with them can you show me some
> >>> links?
>