librelist archives

« back to archive

Re: Rewrite the site via Camping

Re: Rewrite the site via Camping

From:
Fela Winkelmolen
Date:
2010-07-08 @ 21:33
> Hey all-
> 
> Fela, I know you've been checking out the site's code as it is now, and so
> I wanted to bring this up before you get too deep into that.
> 
> I'd been thinking about this for a while now, ever since I started learning
> Sinatra: I think I'd rather re-implement the site via Camping. I think it's
> really important for burgeoning Hackers to be able to learn how web
> programming works too, and I think Rails is too much. I originally wrote
> the site in Rails because it was all I knew. However, I think doing it
> with Camping would make it much easier for new Hackers to learn about.
> 
> Also, now is the time to make a decision like this, before too much site
> code gets written.
> 
> So. I'm 95% sure I want to do this. Unless someone has a big objection.
> Also, if you'd rather just keep contributing to Hackety proper, I don't
> mind doing the site myself, if you don't know anything about Camping.
> 
> Thoughts? Opinions? Anyone? This is a big decision. I'd like to hear what
> other people think.
> 
> -Steve

A kinda lengthy mail with my thoughts about the website.


## About the Rails vs Camping vs Sinatra, I'm no expert at all so I will leave 
the decision on you. 

The only possible drawback that I can see is that maybe someday we evolve to 
the point we will want the full power of Rails. But I suppose we can always 
switch back should the need ever arise.

Perhaps not using Rails may make the website harder to write for us? Like not 
having the ability to just download one of the miriad plugin to have, say, a 
wiki.

I've never used Camping or Sinatra, but I don't mind leaning something new. 
And I've used Rails only very little, so that doesn't make too much of a 
difference.


## Here follows a bit of thinking about the design. We should think about the 
priorities, in a particular way: what do we want to be ready in time for 1.0?

First a consideration about the scope of the application and the website.

The Application should be for writing, editing, testing and executing the 
code. The website for sharing and comunicating. 

Currently the app also notifies for new messages, I'm not sure how useful that 
really is. Email notification of messages would be a lot more useful. I think 
we could for now decide to not duplicate too many features between the website 
and the app. One thing that would be nice to have in the app is documentation, 
because one may need offline documentation (something is there already).


The basic features I think are needed in the website:

- Each user will have a homepage with his info and the list of his programs, 
each listed with name and description, they are clickable and bring up the 
program specific page. I think it could be nice to have comments on the user 
pages too.

- A webpage for every program, with comments. By default I think no program in 
the app should be uploaded without the user saying so. Then he can chose to 
upload one program at a time, or every program in HH. It might be a good idea 
to keep programs synchronized once they have been upload, but if we want to 
use git later, commiting it everytime it's saved might lead to an awfully lot 
of commits, at least if you save files as often as I do... Also: don't we want 
to ask for a commit message? I think it is usually a got habit to always give 
a meaningful message to commits... maybe they will have to learn this habit 
when they start using the real git.

- Programs for one user might quickly become to many to easily manage, some 
sort of folders would be useful (maybe just one level of folders to keep the 
interface simple) 

- There should be the ability to add programs of other people to our own 
collection, so we can easily edit and run them. What about copyright, we could 
for simplicity suppose that all programs posted are given to the public 
domain. We might want to let the user accept some conditions on registration 
to make it legit. A possible feature is that when a program gets "forked" a 
commend gets added at the start: '# original program by <xyz>'

- Messages: with multiple receivers, and the possibility to attach programs, 
which will be shown inline. A forum might use much of the same architecture of 
messages, with the difference that they will be accessible to all. Forums also 
need some kind of categorization...

- using git, I think this will definitely be post 1.0. Do we want backward 
compatibility to the point we already want to track all changes? Seems not 
really trivial to do in an space efficient way...

- wiki, would be nice to have for 1.0

- users being watched by each user (similarly as what currently is 
implemented)


What do you think?

- fela

Re: [hacketyhack] Re: Rewrite the site via Camping

From:
Eric Mill
Date:
2010-07-08 @ 21:49
Definitely don't use Rails for the site. I've been doing nothing but Sinatra
this last year, and even the one Rails site I chipped in on could have been
easily done in Sinatra.

In regards to choosing Camping or Sinatra - use Sinatra.  I've done a lot of
coding in both, and within Camping on both 1.x and 2.0. I've moved to using
Sinatra instead over the last couple years, and I don't regret it.

Is Camping really being maintained, is it growing? I see Judofyr working on
it in Github, and he's the best and most enthusiastic Camping dev I know of
(and he helped me a lot when I was getting Camping working on a shared
hosting environment), but I don't think it's growing at the same pace, or
with the same diversity of contributors, as Sinatra is.

Sinatra also has a larger universe of plugins, many of which are made to
fill in individual gaps that Rails fills, meaning that it's even easier to
avoid having to switch to Rails, by bringing in form generation, or named
routes, or whatever, piecemeal, in a modular fashion.

I <3 Camping, I've given talks on it in the past, and have forced it to work
in a ton of environments out of my love for it - but Sinatra is even more
awesome, and it's the future.

-- Eric

On Thu, Jul 8, 2010 at 5:33 PM, Fela Winkelmolen <fela.kde@gmail.com> wrote:

> > Hey all-
> >
> > Fela, I know you've been checking out the site's code as it is now, and
> so
> > I wanted to bring this up before you get too deep into that.
> >
> > I'd been thinking about this for a while now, ever since I started
> learning
> > Sinatra: I think I'd rather re-implement the site via Camping. I think
> it's
> > really important for burgeoning Hackers to be able to learn how web
> > programming works too, and I think Rails is too much. I originally wrote
> > the site in Rails because it was all I knew. However, I think doing it
> > with Camping would make it much easier for new Hackers to learn about.
> >
> > Also, now is the time to make a decision like this, before too much site
> > code gets written.
> >
> > So. I'm 95% sure I want to do this. Unless someone has a big objection.
> > Also, if you'd rather just keep contributing to Hackety proper, I don't
> > mind doing the site myself, if you don't know anything about Camping.
> >
> > Thoughts? Opinions? Anyone? This is a big decision. I'd like to hear what
> > other people think.
> >
> > -Steve
>
> A kinda lengthy mail with my thoughts about the website.
>
>
> ## About the Rails vs Camping vs Sinatra, I'm no expert at all so I will
> leave
> the decision on you.
>
> The only possible drawback that I can see is that maybe someday we evolve
> to
> the point we will want the full power of Rails. But I suppose we can always
> switch back should the need ever arise.
>
> Perhaps not using Rails may make the website harder to write for us? Like
> not
> having the ability to just download one of the miriad plugin to have, say,
> a
> wiki.
>
> I've never used Camping or Sinatra, but I don't mind leaning something new.
> And I've used Rails only very little, so that doesn't make too much of a
> difference.
>
>
> ## Here follows a bit of thinking about the design. We should think about
> the
> priorities, in a particular way: what do we want to be ready in time for
> 1.0?
>
> First a consideration about the scope of the application and the website.
>
> The Application should be for writing, editing, testing and executing the
> code. The website for sharing and comunicating.
>
> Currently the app also notifies for new messages, I'm not sure how useful
> that
> really is. Email notification of messages would be a lot more useful. I
> think
> we could for now decide to not duplicate too many features between the
> website
> and the app. One thing that would be nice to have in the app is
> documentation,
> because one may need offline documentation (something is there already).
>
>
> The basic features I think are needed in the website:
>
> - Each user will have a homepage with his info and the list of his
> programs,
> each listed with name and description, they are clickable and bring up the
> program specific page. I think it could be nice to have comments on the
> user
> pages too.
>
> - A webpage for every program, with comments. By default I think no program
> in
> the app should be uploaded without the user saying so. Then he can chose to
> upload one program at a time, or every program in HH. It might be a good
> idea
> to keep programs synchronized once they have been upload, but if we want to
> use git later, commiting it everytime it's saved might lead to an awfully
> lot
> of commits, at least if you save files as often as I do... Also: don't we
> want
> to ask for a commit message? I think it is usually a got habit to always
> give
> a meaningful message to commits... maybe they will have to learn this habit
> when they start using the real git.
>
> - Programs for one user might quickly become to many to easily manage, some
> sort of folders would be useful (maybe just one level of folders to keep
> the
> interface simple)
>
> - There should be the ability to add programs of other people to our own
> collection, so we can easily edit and run them. What about copyright, we
> could
> for simplicity suppose that all programs posted are given to the public
> domain. We might want to let the user accept some conditions on
> registration
> to make it legit. A possible feature is that when a program gets "forked" a
> commend gets added at the start: '# original program by <xyz>'
>
> - Messages: with multiple receivers, and the possibility to attach
> programs,
> which will be shown inline. A forum might use much of the same architecture
> of
> messages, with the difference that they will be accessible to all. Forums
> also
> need some kind of categorization...
>
> - using git, I think this will definitely be post 1.0. Do we want backward
> compatibility to the point we already want to track all changes? Seems not
> really trivial to do in an space efficient way...
>
> - wiki, would be nice to have for 1.0
>
> - users being watched by each user (similarly as what currently is
> implemented)
>
>
> What do you think?
>
> - fela
>

Re: [hacketyhack] Re: Rewrite the site via Camping

From:
Steve Klabnik
Date:
2010-07-08 @ 22:02
>
> In regards to choosing Camping or Sinatra - use Sinatra.


That'd seem to be consistent with the research I've been doing over the last
day or two... you're right. It's not being maintained as actively, and
Sinatra has a much larger base of pretty much everything.

Re: [hacketyhack] Re: Rewrite the site via Camping

From:
Devyn Cairns
Date:
2010-07-08 @ 22:20
Almost all of Sinatra is inspired by Camping; I would almost say Sinatra is
the successor to it.

Yes, Camping is pretty neat—but I'd say Sinatra is more usable, the code
looks cleaner, etc. It's like Camping on steroids.

On Thu, Jul 8, 2010 at 3:02 PM, Steve Klabnik <steve@steveklabnik.com>wrote:

> In regards to choosing Camping or Sinatra - use Sinatra.
>
>
> That'd seem to be consistent with the research I've been doing over the
> last day or two... you're right. It's not being maintained as actively, and
> Sinatra has a much larger base of pretty much everything.




-- 
   ~devyn