+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.defe...@gmail.com> > 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.
