Daniel - that's a great reply and echoes much of my own experience
(although my Camping is much more on the tinkering side). The point
about Camping being an educational tool is a good one, which I've even
tried to apply to students (unsuccessfully - but that's my problem),
and it would be nice to see Camping as the next step after the nicely-
redesigned 'Try Ruby' - DaveE
Thought I'd weigh in for what it's worth,
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.
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?
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.
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?
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.
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.
On Wed, Apr 18, 2012 at 10:35 AM, Jenna Fox <a...@creativepony.com>
wrote:
Those are all great points - the eventstream support is a particular
sticking point to me. It feels like a standard which aught to be
easily implemented - even through rack! but I've yet to see any web
frameworks where eventstream doesn't seem like a total hack - except
perhaps for Node.JS where the http server class is so low level
anything seems equally easy. I'm not yet convinced WebSocket is
useful for very much - it's not well supported in http servers and
reverse http proxies, and it's full-duplex nature seems unnecessary
when ajax is good enough for responding in most situations. On the
other hand, websockets doesn't even pretend to be anything like a
http request aside from setup negotiation, so there's no implication
that a web framework designed for serving pages should really have
anything to do with websocket - much of the websocket standards
specify outputting strings which look like http, but not really
parsing http headers properly or anything.
I'd love to see some inventive solutions to long polling and event
stream. Rack does seem to be increasingly a source of pain. The
guardians of the rack spec haven't done a good job keeping up with
new tech.
All your other points, I totally agree. Especially regexp routes. I
feel like the camping feature for generating routes from controller
names is not as good as just having a friendly route language.
One thing I never liked about rails was having routes in a separate
file somewhere, then just some controllers named whatever files. I
wonder if the controller routes couldn't also be the controller's
filenames? I guess some operating systems wouldn't much like
filenames with forward slashes in them though (windows..)
—
Jenna
On Wednesday, 18 April 2012 at 6:15 AM, Magnus Holm wrote:
On Mon, Apr 16, 2012 at 22:27, Nokan Emiro <uzleep...@gmail.com>
wrote:
For now I'm feeling like a pretty bad "maintainer". I'm not using
Camping enough to see where things need to be fixed, I'm crappy at
actually shipping stuff, and I'm not sure if I believe that
Camping is
a correct starting point for a new framework.
Like so many times before, I have a few silly questions again:
There's no silly questions; just puzzled people who don't dare to
ask :-)
- Why do you think so that Camping isn't a good starting point?
I like centralized routing (config/routes.rb vs having routes in the
controllers). It's also easier to combine a Sinatra-style-framework
with centralized routing: just allow routing to a block, and `get "/"
do … end` is as natural as `routes.get "/", :to => "home#index"`.
I prefer Sinatra-style routes over regexps.
Camping's module magic is just plain bad style. Inheritance is easier
to work with.
Mapping one URL to one class is a little too verbose for me; I end up
with tons of classes and it's hard to see which classes that actually
work on the same type of data. For controller classes, Rails-style is
more pragmatic.
It's just 4k; that's hardly any starting point at all :-)
- What is the problem with Camping in your opinion?
There's not a "problem" with Camping. It's an elegant piece of code;
it solves HTTP in a surprisingly "correct" way, although it's not
always so pragmatic/practical.
- What does a good framework provide for you?
...and the most stupid one:
- Why are you talking about a "new framework"? Why don't we
rewrite Sinatra, Ramaze or whatever over Camping? They have
an interface that's used by others...
I just feel like the whole Ruby framework community stagnated a few
years after we got Rack. The moment Rack became properly implemented
everywhere it lacked any kind of
EventStream/WebSocket/long-polling-support. Everything since then has
been hacked on top.
Rails provides ActiveRecord for database access, but more and more
stuff these days are using HTTP. I believe that a true *web*
framework
should provide a HTTP client/user-agent too. Net::HTTP doesn't cut it
(no persistant connection support in stdlib; rather
verbose/inconsistent and no cookie-jar). There are other libraries,
but these have their own conventions and limitations.
_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
