> 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 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.
yea, if you do gem install merb-core, gem install merb > >> 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. As you say below there are some aspects that are not clean: - merb-actions-args - merb-params-protections And for me - merb-auth - merb-slices > > >> 2) Make merb a little smaller (in terms of gems) > > Smaller than one ;-) One with a lot of dependencies (if you mean gem install merb) > > >> 3) Make merb more stable but revolutionary >> > > Haven't had any stability issues and we use it in production across a > cluster. At the moment Im not using it in production, but seeing some commit don't seems to be right (for the use of merb that I need) - Little dependency issue http://github.com/merb/merb/commit/7fc90aac1ae4204cafa7afb3a83899f05e11ddec - New repo http://github.com/merb/merb/commit/a95a90b1fcc80897b32ed064d8defba3dd268306 - Caching problem http://github.com/merb/merb/commit/923406abf993b4e82938a342c506dff1e0abcad5 - helpers (select) problem http://github.com/merb/merb/commit/e2e3866efa39e5a307fdd406005e0012c02e3c90 ... I know that for example rails have some than 100+ commits for day, but the posted thing above for example for me was braking problem. > >> 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 For example if I need merb-gen admin I can (because merb is flexible) build my own generator. >> >> 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. Yea, but for me the first time that I see It I was confused. >> >> 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 Im also, (In my fork i merge It in the core) and then a member of the team tell me about that. > >> 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. Is that I mean: make merb more concise > >> 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? I think core team at the moment need to focus only on: - merb-core - merb-cache - merb-assets - merb-gen - merb-helpers - merb-mailer And (at the moment) forget to spent a lot of times on other gems. > > >> 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! As I say before I tried a lot of times to make a production websites with merb but always I found a breaking problem. > > >> 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: 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? >> - 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. > > >> >> 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" Yea, but I think that mantain and make good docs about: - merb-actions-args - merb-exceptions (remember I love it) - merb-param-protection - merb-slices If the merb team was reduced is wasted time... no? > > > Chris > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
