> I read several comments about how easy it is to upgrade Rails. > Either things have been improving at the speed of light or I am > a complete idiot. My last upgrades from 2.x to 2.y have been > nightmares, dependency hell multiplied by an unknown factor > above 100...
I strongly agree. I think of upgrading as the major pain point in the Rail eco-system. It has gotten better, but as recently as last week I was trying to upgrade a gem and ran into version conflicts. Search StackOverflow for Bundler error messages and you realize this is still a huge point of pain -- there are thousands of people struggling to deal with cryptic version conflict errors, and unable to get Bundler to resolve the problem for them. On Monday, May 4, 2015 at 10:42:15 AM UTC-4, Luc wrote: > > +1 > > This exactly the kind of exercises that needs to done as part of a > product design. New potential needs have to be foreseen at this > stage, not 18 months after a first release. > > This is why I hate frameworks, they assume some of these > decisions and it's not always stated clearly. Someone has to > discover the sad effects and if you are not lucky, you're the 'king of the > farce'. > > They lure you in a trap pampered with 'easy', 'obvious'... Until > you have a need that cannot be met along the way. > > I read several comments about how easy it is to upgrade Rails. > > Either things have been improving at the speed of light or I am > a complete idiot. My last upgrades from 2.x to 2.y have been > nightmares, dependency hell multiplied by an unknown factor > above 100... > > I would rather deal with an explicit dependency graph than > work with magic stuff that eventually breaks in obscure ways > after an upgrade and requires mods in remote places in foreign code. > > Luc P. > > > The thing that bugs me the most about these sort of conversations about > > "best practices" is that they often present a set of solutions without > > first analyzing the problem at hand. > > > > If I came to this mailing list and asked "I want to write a websever in > > Clojure..what should I use?". The response would most likely be Ring + > > Compojure. Okay, not bad options, but that recommendation has been given > > with absolutely no analysis of what I'm trying to accomplish. What if I > > need async? What if I need web sockets? What sort of connection load am > I > > expecting? Will my system handle mostly persistent connections (like > > websockets or SSE), or will it be more canned (and cacheable) data? If > > someone recommends Ring to me, I may be pigeonholed into some system > I'll > > have to refactor later. Perhaps the best option is Aleph or Pedestal. > > > > That's the real issue with canned responses like rails tutorial. They > > assume my needs match your needs and match the needs of most people. > That's > > just not the best way to go about doing software development. And it's a > > problem I've seen in so many areas of computing. > > > > I've lost countless hundreds of hours of my life to frameworks that > default > > to bulky serialization formats (like XML or JSON), or frameworks that > > assume LAN connections to the servers, or frameworks that assume I won't > be > > using multi-threading, or frameworks that assume I won't try to load 10k > > rows on a single page, or frameworks that assume any number of things. > The > > thing I love the most about the Clojure community is that, more than any > > other community I've been a part of, they try to ask you to think before > > you jump. > > > > So what I would recommend is more of a set of guidelines, and matrices. > > List all the frameworks/libraries on one axis, and features on another, > and > > start commenting. Make a page like this: ( > > http://en.wikipedia.org/wiki/Comparison_of_video_container_formats) > > > > Mention that Ring is well supported by the community, but doesn't work > well > > with fully async servers, mention that Aleph does all the async you > need, > > but is a bit non-standard. Mention that data.json is pure Clojure, but > > cheshire is most likely faster. > > > > Just present the options, and let the users make up their own minds. You > > don't understand the needs of all of your users. So don't try to solve > > their problems, instead present them with options and let them make up > > their own minds. I guarantee you that whatever tech you recommend to > > someone, the won't like some aspect of it, so better to present them > with > > all the options and let them choose, then they can only blame themselves > if > > it doesn't work out exactly like they expected. > > > > > > > > On Mon, May 4, 2015 at 7:34 AM, Ernie de Feria <ernie....@gmail.com > <javascript:>> > > wrote: > > > > > I would like to echo the sentiment expressed by several posters in > this > > > thread, but with a slight twist. A few years back I picked up Ruby and > Ruby > > > on Rails as the language/framework to create a website with moderate > > > complexity and functionality. I did this without any prior experience > with > > > the language of framework. What allowed me to quickly pick up both was > the > > > excellent documentation around the language and framework. For > example, > > > with the information from http://guides.rubyonrails.org and the > canonical > > > application built in https://www.railstutorial.org one can acquire > the > > > necessary knowledge to develop highly functional websites. Branching > out to > > > leverage "non-canonical" libraries/products then becomes a fairly easy > > > exercise (MongoDB instead of MySQL, Mongoid instead of ActiveRecords, > > > etc.). What allows that to happen is the momentum built around the > Rails > > > ecosystem via community participation and documentation. > > > > > > We have recently started to build our "back end" infrastructure in > > > Clojure. Many times we have discussed the value and desire to unify > our > > > development efforts on and around Clojure. Inevitably we tally up all > the > > > functionality inherited from Ruby gems (that play nice with Rails - > the > > > Framework) that would have to be replicated in Clojure and there > always > > > shortcomings, not necessarily in the availability of libraries that > perform > > > these functions, but in the readily accessible documentation about how > to > > > best integrate them. > > > > > > The "composable libraries over framework" mantra is technically solid -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
