On Wed, Apr 18, 2012 at 15:07, Daniel Bryan <danbr...@gmail.com> wrote: > Thought I'd weigh in for what it's worth,
Thanks, I find it very interesting. > My naive first impression of Camping basically took no notice of the whole > 3/4k thing. I appreciate that it's a cool programming feat, and I love the > attitude that lead to it, but at the time my focus was on trying to figure > out what all these hidden instance variables you have in a controller are > (the documentation was only of sporadic use), thinking I might just dive > into the source to check it out, and obviously being confronted by the fact > that even the unabridged code is far from readable (as it wasn't intended to > be). > > I discovered Camping when I was very new to Ruby, and relatively new to > programming in general. Everyone here obviously knows the strengths and > reputation of Ruby - and projects like Camping - as a learning language. > > I've mostly moved onto working in Python, but I think there's a strong > chance that my understanding of the architecture of web applications, and > HTTP, and my motivation to understand web development at several different > layers, would have been different if Camping didn't imply a certain kind of > thinking that coloured my behaviour. Hm… What parts of Camping did this? What does Camping have in this department that e.g. Rails or Django don't? > So why not build on this? There's all sorts of amazing projects all over the > web at the moment for making programming accessible to people who are very > young, or who have literacy that's poorer than most programmers, or who live > in the third world, or who just come from subcultures / cliques where > usually you wouldn't do this kind of thing. That's cool, but as soon as > these people learn some stuff they want to do something, and they want to do > it either with mobile or the web. They google around and they find out > about, like, what? Rails? Django? What a way to turn people off. > > One of the reasons I floundered with Camping after a while is that it was > really hard to figure out where to, you know, put a lot of my code. Helpers? > I guess. This is a pretty typical problem in web frameworks, obviously - > where do you put domain-specific logic? Where do you store all your > application logic? How lightweight should your controllers be? Do you want > fat models? Heh, I find this fascinating. People desperately want the framework to have a place for everything. Just give it a good name(space) and place it in lib/. That's where all code belongs. I'm thinking of reviving lib/ for all code (controllers too!) if I ever start a framework. > I think ActiveRecord is the elephant in the room here - very quickly I ended > up using models in my apps that were just representations of the filesystem, > or of some other API, or of documents in CouchDB, or whatever. That was > cool, and Camping made that relatively easy, but the fact is I'm not an API > designer. I'm not a library writer. Any ad-hoc decision I make about how I > might model my data, as an amateurish programmer, is going to be disastrous, > but ActiveRecord just couldn't do what I wanted to do without more work than > it was worth. I agree. SQL + migrations is hard. Camping's migrations are not good enough. They should probably never have been inside the main file… > So maybe if there was some kind of Camping fork, or a new Camping-inspired > framework, or whatever, it could try to encapsulate not just this solid core > focused on using class methods as HTTP verbs, but also some kind of pattern. > What's the next thing someone needs to know after they're good with Camping? > How to write their library code. How to manage the dependencies (ugh). How > to deploy it (it took me forever to even figure out that I needed something > called a 'rackup' file - I eventually found a Heroku guide for Camping, and > even then I couldn't get it to work until I stole some code from some > project of Magnus' or Jenna's). > > I'm being incoherent, but in general I think my attraction as a novice to > Camping was for it clarity - not even necessarily its simplicity. Why not > bring that clarity to the rest of the web development process that surrounds > it? I agree with this: I'd love a framework that integrates with different tools (Bundler, RVM, rbenv) to provide the best experience. You should be able to run "bin/myapp server" and it should either work or it should give you clear instructions on how to fix it. > People keep talking about Sinatra. Personally - as a completely subjective, > essentially arbitrary position - I don't like Sinatra. Whatever you think of > it, I think it's possible to point out that we don't need to just look > inside the Ruby environment. Why not look at other places where interesting > things are happening? Node's "Express" framework, for instance, bears a lot > of similarity to Sinatra and Camping; the "Connect" middleware framework > that it uses is similar to Rack in many ways. The difference is that their > community actually brags about it, and makes a point of how much easier your > life could be if you use it for lots of stuff. It looks like there was > similar excitement about Rack back in the day, but it doesn't come across > that way so much. Maybe just because of the shadow of Rails hanging over > everything. It's just like when we bragged about Rack while the Python guys where like "duh, it's just a cool abstraction, not mind-blowing or anything". Most of the time I see people bragging about some technology it just seems that they've reinvented something. But yeah, I think there's plenty to learn from Node.js. Not to forget Perl (who would have thought that?) which currently has the best web framework I've ever seen: http://mojolicio.us/ > Sorry for ranting a little - I keep reading this thread on the way to work > and wanting to comment but not having time. In summary - I'm greatful for > what Camping provided me as a learning environment, but I think it could go > a lot further in supporting the growth of developers who used it, and > helping them to do stuff 'correctly' outside of their controllers. > > It's obvious that sockets and so on excite a lot of young programmers - > especially as so many of them have JavaScript as their first language now, > but I can't imagine how you'd support something like that properly in > something like Camping without building it on top of an event-driven > framework. Exactly. _______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
