Re: Wiki vs homepage

[Dave Everitt]

Not from me. ruby-camping.com is fine and I'm aware of the SEO  
implications. My offer of server space (on our Linux VPS + Ruby 1.9)  
still stands - Dave E



On 25 Jul 2010, at 16:04, Philippe Monnet wrote:

Also in the spirit of SEO, maybe we just need to have multiple  
domain names all linking back or redirecting to ruby-camping.com. I  
am willing to buy and commit to ruby-camping.com so anyone else is  
free to buy campingrb.com or any other naming permutation they  
like. This way we can all have our cake and eat it too!

Any objections at this point on me moving forward?


On 7/23/2010 12:19 PM, Dave Everitt wrote:
May not be attractive, but if it's already a ruby-related meme,  
worth considering - Dave E



On 23 Jul 2010, at 17:38, Philippe Monnet wrote:



My preference would be to have Ruby explicitly mentioned in the  
name and a clear easy-to-read url. This makes it a bit more SEO  
friendly too which is important for a promo site. IMHO suffixing  
with rb is not very visually attractive.



On 7/23/2010 9:39 AM, Steve Klabnik wrote:

I don't know if it's available or not, but why not  
campingrb.com rather than ruby-camping.com? Many of the other  
small web frameworks follow this url scheme (sinatrarb and  
padrinorb).




___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Wiki vs homepage

[Philippe Monnet]

Also in the spirit of SEO, maybe we just need to have multiple domain 
names all linking back or redirecting to ruby-camping.com. I am willing 
to buy and commit to ruby-camping.com so anyone else is free to buy 
campingrb.com or any other naming permutation they like. This way we can 
all have our cake and eat it too!

Any objections at this point on me moving forward?

On 7/23/2010 12:19 PM, Dave Everitt wrote:
May not be attractive, but if it's already a ruby-related meme, worth 
considering - Dave E


On 23 Jul 2010, at 17:38, Philippe Monnet wrote:

My preference would be to have Ruby explicitly mentioned in the name 
and a clear easy-to-read url. This makes it a bit more SEO friendly 
too which is important for a promo site. IMHO suffixing with rb is 
not very visually attractive.


On 7/23/2010 9:39 AM, Steve Klabnik wrote:


I don't know if it's available or not, but why not campingrb.com 
rather than ruby-camping.com? Many of the other small web 
frameworks follow this url scheme (sinatrarb and padrinorb).




___
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

Re: Wiki vs homepage

[Dave Everitt]

May not be attractive, but if it's already a ruby-related meme, worth  
considering - Dave E


On 23 Jul 2010, at 17:38, Philippe Monnet wrote:

My preference would be to have Ruby explicitly mentioned in the  
name and a clear easy-to-read url. This makes it a bit more SEO  
friendly too which is important for a promo site. IMHO suffixing  
with rb is not very visually attractive.


On 7/23/2010 9:39 AM, Steve Klabnik wrote:


I don't know if it's available or not, but why not campingrb.com  
rather than ruby-camping.com? Many of the other small web  
frameworks follow this url scheme (sinatrarb and padrinorb).




___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Wiki vs homepage

[Dave Everitt]

Anyone know who did this:
http://camping.tumblr.com/
?

Dave E

Jenna: I suggest a tumblr, because it doesn't cost anything, can  
have group committers, all the features we need, and it too is  
connected to the rich heritage of _why :)

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Wiki vs homepage

[Philippe Monnet]

My preference would be to have Ruby explicitly mentioned in the name and 
a clear easy-to-read url. This makes it a bit more SEO friendly too 
which is important for a promo site. IMHO suffixing with rb is not very 
visually attractive.


On 7/23/2010 9:39 AM, Steve Klabnik wrote:
I don't know if it's available or not, but why not campingrb.com 
 rather than ruby-camping.com 
? Many of the other small web frameworks 
follow this url scheme (sinatrarb and padrinorb).


Or maybe not. I just think it's an interesting url for Ruby projects.


___
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

Re: Wiki vs homepage

[Dave Everitt]

Hi Steve - I really like that idea. Of course, someone (us) is going  
to have to actually purchase the domain at some point :-) - Dave E


I don't know if it's available or not, but why not campingrb.com  
rather than ruby-camping.com? Many of the other small web  
frameworks follow this url scheme (sinatrarb and padrinorb).


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Wiki vs homepage

[Steve Klabnik]

I don't know if it's available or not, but why not campingrb.com rather than
ruby-camping.com? Many of the other small web frameworks follow this url
scheme (sinatrarb and padrinorb).

Or maybe not. I just think it's an interesting url for Ruby projects.
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Wiki vs homepage

[Philippe Monnet]

Ok I would really like to get the promo site going so that we have 
something up and running before Why Day (Aug 19th per 
http://whyday.org/). I propose the following:


  1. I can go ahead and buy the ruby-camping.com domain - should 
someone also buy the .org equivalent? I think the promo site has to have 
a straightforward name related to ruby and camping (similar to 
ruby-lang) to make it easy for people to remember the site or search for 
it. (We can use whywentcamping.com for something else like either the 
doc site or the site focusing on learning and hosting simple apps - see 
Jenna's ideas on this)


  2. Until we know what other things we want to do with 
ruby-camping.com in terms of showcasing apps and all, I can either host 
the site:
 a) at my host (1&1 - ok for now with straight content only - 
the downside is I will be the bottleneck for updates
b) or deploy it on Heroku - we can have multiple collaborators 
to push content via git. This would also give us more flexibility in the 
long run (like diff versions of Ruby, db, plugins, etc - and maybe we 
can get sponsored


  3. For the time being I will leave the site as straight HTML and 
Javascript (we can switch it to Camping+Tilt later)


  4. I will create a ruby-camping.com project under camping in GitHub 
and upload the content. This way anyone can contribute to the design - 
wink wink uh-hmm Jenna/Dave/Matt/... ;-)


Let me know if you're ok with this or provide alternatives.
I'd like to get this done this week-end.

Philippe (@techarch)

On 7/8/2010 1:55 PM, Magnus Holm wrote:

Hey guys,

Philippe had some interesting points about the website:

1. Keep the home page simple with all content fitting within 1280 x 1024
2. Use a catchy design (need some help here)
3. Accentuate that Camping is about Ruby (maybe also include the ruby
logo somewhere)
4. Have a brief note about the connection to _why and a link to a page
explaining the history of Camping with further links to _why's other
sites
5. Encourage people to try it by capitalizing on some of Camping's strengths:
- Fast to learn - requires only basic Ruby skills
- Much simpler than Rails but more structure than Sinatra/Padrino
- Lightning fast and memory efficient allowing fast and efficient sites
- Can evolve from simple file to organized directory structure
- Can layer in more features later using persistence and choice of view engines
6. How about using some kind of an animated (auto advancing) slideshow
to highlight some of the benefits? See an example at:
http://blog.monnet-usa.com/?p=276
7. How about a page on learning with a link to the book as well as a
list of links for other tutorials or short explanations on key topics
(e.g. how to do migrations, how to use include/extend, how to use
different view engines, etc.)?
8. How about a page about plugins with some brief description of their intent?
9. I would love for us to include _why's cartoons in some of the sub pages ;-)

Now, the more I look at this list (and my own thoughts about the new
camping site) I realize that we're talking about two different things:

* A site to attract new users
* A site to inform regular users

It looks like my attempt (http://whywentcamping.judofyr.net/) tries to
target the latter, while Philippe targeted the former
(http://rubycamping.monnet-usa.com/). Both sites serves a purpose and
I believe both are equally important.

--

Here's what I propose: We split the site into two parts. We turn what
I've created into a wiki. Everyone are welcome to edit and add their
own content.

Then we take Philippe's ideas/design/site and turn it into
ruby-camping.com or whywentcamping.com or whatnot. It probably doesn't
need to be more than a single page.

What'd ya think?

// Magnus Holm
___
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

Re: Wiki vs homepage

[Dave Everitt]

Jenna - just to say I really agree with your post and - but for some  
pressing paid work - would respond in more detail. The education  
thing is a real opportunity - Dave Everitt


I propose this: We settle on the idea that we are in fact an  
awesome bunch and that camping still has that wonderful educational  
essence of it's beginnings, and that being loosely connected to  
_why, we already have some weight with educators. There are  
computer labs full to the brim with boxes doing nearly nothing in  
schools all around the place!


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Wiki vs homepage

[Jenna Fox]

I love the idea of having Key/Value databases available to camping apps as a
standard thing on the platform. They aren't the same thing as a filesystem
though, and I don't think we should pretend otherwise. If we don't want to
give users filesystem access, that's *fine*, even though I don't see why we
shouldn't.

What about this - We make a sister project, ForeverHash, which works just
like a normal hash except that when you .new it you have to give it a name,
like ForeverHash.new(:people), resulting in people.db existing some place in
the filesystem. We could have a campers-toolkit gem which would default to
using yaml or marshal or whatever to shove that stuff in a file on close,
and read it in on launch. When stuff like TokyoCabinet is available, it'd
just magically be faster and awesomer.

campers-toolkit could have tons of neat little bonus toys like that.

Thing is, Heroku is this big scary thing which is all about performance and
big deployments and commercialisation and not at all about learning and
hacking and making stupid little games and programs that do your math
homework for you (that's why I learnt to write basic!). We already have
Heroku. We don't need another abstraction to it. Fake filesystem atop a
key/value database would be a fun hack, but it'd go crazy with things like
the exotic file locks sqlite uses.

I propose this: We settle on the idea that we are in fact an awesome bunch
and that camping still has that wonderful educational essence of it's
beginnings, and that being loosely connected to _why, we already have some
weight with educators. There are computer labs full to the brim with boxes
doing nearly nothing in schools all around the place! The internet itself
was practically born of excessive computing power at universities needing to
find something to do with itself!

So I propose we stop eating the little scraps of free stuff the capitalist
processes that drive services like heroku and dreamhost produce, and really
try and pester the educational systems of the world - see if they'll give us
a server and plug it in to some pipes to get this idea going. If we can get
a dedicated server somewhere, making secured little app hosting is trivial
and fun and super easy to do!

Web hosting friends inform me that linuxes have no worries at all with
hundreds of thousands of user accounts. That's how tryruby worked way back
when - it made a new user account when you entered your first command, ran
it, and removed the account if it idled out. That's how try ruby was secure!
All we need to do is use the same tools shared webhosts have been using for
decades, like unix file permissions and apache or ngynix and passenger and
chroot and a user account per user or app, and we have a totally viable way
to do this. Passenger will run as many processes as each app needs, and shut
them down when nobody is using that app. The ruby processes can run under
that user's account, and we can automatically apply permissions to the files
as they're uploaded and updated. Then we just short out the system/``/chown
type commands in the ruby process with a little bootstrap code added to the
rackup and we've got it sorted.

The tech here is easy and fun. Getting a server to run it on could be tricky
- but we have avenues to explore. We NEED to get a good website up with a
blog (I suggest a tumblr, because it doesn't cost anything, can have group
committers, all the features we need, and it too is connected to the rich
heritage of _why :)

Then we can put the callout. Once a plan is formed for the tech and the look
of the thing, we can get a blog post up explaining the idea and asking for
help, and start mailing it around to universities and schools, asking if
they have any extra servers they might donate to the cause.

Carnegie Mellon physically hosted art && code. Maybe they'd host us too!

// Sidebar: Okay, so yaml and marshal would suck as a backend because it'd
go crazy without any obvious reason if the user launched multiple processes,
as they may well do if using lighttpd. Still, it doesn't have to be *fast*,
so maybe there's some sort of compramise to be had? Marshal the values, and
store them in some sort of indexy thing, where we could use filesystem locks
to keep from writing over eachother, and garbage collect / compress every
now and then. That could work really well, and could be nice pure ruby.
Mmmm. Is this crazy? Am I a nut for thinking that a simple multiprocess safe
key/value store would actually be really easy to do? I've played with the
filesystem as a storage medium a fair bit.. it seems like it should be
almost trivial! Maybe I should make this right now!

On Sat, Jul 17, 2010 at 11:05 PM, Philippe Monnet wrote:

>  I think having a section off of the promo site (and linked from the wiki
> too) to showcase simple user-created apps is a great idea as I have not seen
> that concept on other sites.
> I believe Magnus is building a TryCamping thing too which would be awesome
> too.
>
> I agree

Re: Wiki vs homepage

[Philippe Monnet]

I think having a section off of the promo site (and linked from the wiki 
too) to showcase simple user-created apps is a great idea as I have not 
seen that concept on other sites.
I believe Magnus is building a TryCamping thing too which would be 
awesome too.


I agree with the fact that making it easier for kids/teens to play with 
Camping would be fantastic.
I am not sure exactly how to make that happen but you are onto something 
with monkey patching part of Ruby too make it safer / easier to do that.


/!\ warning - stream of consciousness coming up ...

How about if we used a key-value store (like 
CouchDB/MongoDB/TokyoCabinet/...) as an application repository? Here is 
a potential scenario assuming a Camping "enthusiast" already has an app 
working locally on their box:

  1-Enthusiast chooses to create an app in the "CampingGround" / sandbox
  2-We create a definition for the app as well as a source file based 
on an minimal template

  3-We store both in the key-value db
  4-We mount the app and wire the reloader to look for timestamp 
changes on the key-value store record
  5-Enthusiast uploads the code - saves commit the code changes to the 
key-value store

  6-Enthusiast runs the mounted app

Maybe we could convince a host like Heroku to facilitate this.
Is this crazy? Any other ideas?

-Philippe

On 7/13/2010 8:49 PM, Jenna Fox wrote:
Another passing thought: It'd be very much in the spirit of freeform 
fun little hacks if the camping website included a section of user 
created apps. They would need to be moderated somehow, unless someone 
were to set up a try-rubyish highly sandboxed environment to run them. 
It just seems like there'd be no better way to show what Camping is 
all about than to have it's very own website full of fun little 
examples of camping apps, with a way to see the source code of each 
right in there. If you guys had something like that, i'd love to 
contribute some quirky little multiplayer games, and an extremely 
simple chat thing. :)


What with rack mounts, this should be easy, right?

Why did say at art & code that he didn't really care if the code 
editor part of HetyH was really good - what mattered was the sharing. 
The forum. The code messaging system. The apps which could talk to 
each other over the web through the various APIs. That was the 
important part of hackety hack. I think that's the important part of 
camping as well. The main reason I use Camping over Sinatra and the 
likes is the way it feels so warm and fuzzy, and I know if I have any 
troubles, I get to come talk to all you awesome people. :)


If we had the sandboxed thing, it'd be fairly trivial to include a 
little cli app in the camping gem to upload the app in to a whyism or 
hetyh or whatever account, where it could sit in a little bin of 
recent uploads, and be attached to forum posts, or shared out like 
tinyurls.


The most important part of all that is kids. Kids don't have web 
servers. It's all well and good to have camping ourselves, but if 
we're to think for one minute that we're helping kids learn ruby 
(which after all, was _why's mission), we've got to be offering some 
fairly easy way for them to host this stuff.


Does anyone know much about sandboxing? Anyone know if it'd be 
particularly difficult to do things like monkeypatch the IO class to 
effectively chroot and secure a camping app? Can we disable `system 
calls` too? What's involved in making something like that viable? 
Hosts like Dreamhost seem to already be making use of Passenger to 
dynamically allocate ruby processes to apps, so they can be booted up 
when requested and shut down after they idle for a minute. :)


—
Jenna Fox
http://creativepony.com/


___
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

Re: Wiki vs homepage

[Philippe Monnet]

Jenna, it would be fun to incorporate your cartoons in both the promo 
site and the wiki.


On 7/13/2010 8:34 PM, Jenna Fox wrote:

I agree wholly on the design front, and would like to contribute cartoony 
doodles and simple (not Backend Web Developer simple, but Designer Simple) web 
designs in vaguely _why's quirky fun style, if you guys are up for that. I'm 
currently rather more focused on Hackety Hack's web stuff, but in a couple of 
weeks when I get tired of drawing fruit bats and laser-breathing dinosaurs, 
Maybe camping would be a fun place to doodle? :)

If I forget, poke me @Bluebie.

@Judofyr - if you want to chat, I am a...@creativepony.com on msn/jabber these 
days. :)

Oh, and I don't know what the others think of this idea, but there is some talk 
of HetyH having a forum in the next refresh of it's website. How would you guys 
feel about being a part of that? I'm rather fond of the idea of reuniting the 
old _why community in some common shared space like that, though I'd fully 
understand if you guys feel it'd be a smelly situation to be a category in 
another project's forum.

Maybe instead - if you guys are pro-forum - there could be a website.. perhaps 
named something like 'Whyism', a special little cult of _why place for us all 
to hang out and talk about all his old projects, and our new stuff too. To keep 
the spirit of it all alive?

—
Jenna Fox
http://creativepony.com

On 09/07/2010, at 5:55 AM, Magnus Holm wrote:

   

Hey guys,

Philippe had some interesting points about the website:

1. Keep the home page simple with all content fitting within 1280 x 1024
2. Use a catchy design (need some help here)
3. Accentuate that Camping is about Ruby (maybe also include the ruby
logo somewhere)
4. Have a brief note about the connection to _why and a link to a page
explaining the history of Camping with further links to _why's other
sites
5. Encourage people to try it by capitalizing on some of Camping's strengths:
- Fast to learn - requires only basic Ruby skills
- Much simpler than Rails but more structure than Sinatra/Padrino
- Lightning fast and memory efficient allowing fast and efficient sites
- Can evolve from simple file to organized directory structure
- Can layer in more features later using persistence and choice of view engines
6. How about using some kind of an animated (auto advancing) slideshow
to highlight some of the benefits? See an example at:
http://blog.monnet-usa.com/?p=276
7. How about a page on learning with a link to the book as well as a
list of links for other tutorials or short explanations on key topics
(e.g. how to do migrations, how to use include/extend, how to use
different view engines, etc.)?
8. How about a page about plugins with some brief description of their intent?
9. I would love for us to include _why's cartoons in some of the sub pages ;-)

Now, the more I look at this list (and my own thoughts about the new
camping site) I realize that we're talking about two different things:

* A site to attract new users
* A site to inform regular users

It looks like my attempt (http://whywentcamping.judofyr.net/) tries to
target the latter, while Philippe targeted the former
(http://rubycamping.monnet-usa.com/). Both sites serves a purpose and
I believe both are equally important.

--

Here's what I propose: We split the site into two parts. We turn what
I've created into a wiki. Everyone are welcome to edit and add their
own content.

Then we take Philippe's ideas/design/site and turn it into
ruby-camping.com or whywentcamping.com or whatnot. It probably doesn't
need to be more than a single page.

What'd ya think?

// Magnus Holm
___
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

Re: Wiki vs homepage

[Jenna Fox]

Another passing thought: It'd be very much in the spirit of freeform fun little 
hacks if the camping website included a section of user created apps. They 
would need to be moderated somehow, unless someone were to set up a try-rubyish 
highly sandboxed environment to run them. It just seems like there'd be no 
better way to show what Camping is all about than to have it's very own website 
full of fun little examples of camping apps, with a way to see the source code 
of each right in there. If you guys had something like that, i'd love to 
contribute some quirky little multiplayer games, and an extremely simple chat 
thing. :)

What with rack mounts, this should be easy, right?

Why did say at art & code that he didn't really care if the code editor part of 
HetyH was really good - what mattered was the sharing. The forum. The code 
messaging system. The apps which could talk to each other over the web through 
the various APIs. That was the important part of hackety hack. I think that's 
the important part of camping as well. The main reason I use Camping over 
Sinatra and the likes is the way it feels so warm and fuzzy, and I know if I 
have any troubles, I get to come talk to all you awesome people. :)

If we had the sandboxed thing, it'd be fairly trivial to include a little cli 
app in the camping gem to upload the app in to a whyism or hetyh or whatever 
account, where it could sit in a little bin of recent uploads, and be attached 
to forum posts, or shared out like tinyurls.

The most important part of all that is kids. Kids don't have web servers. It's 
all well and good to have camping ourselves, but if we're to think for one 
minute that we're helping kids learn ruby (which after all, was _why's 
mission), we've got to be offering some fairly easy way for them to host this 
stuff.

Does anyone know much about sandboxing? Anyone know if it'd be particularly 
difficult to do things like monkeypatch the IO class to effectively chroot and 
secure a camping app? Can we disable `system calls` too? What's involved in 
making something like that viable? Hosts like Dreamhost seem to already be 
making use of Passenger to dynamically allocate ruby processes to apps, so they 
can be booted up when requested and shut down after they idle for a minute. :)

—
Jenna Fox
http://creativepony.com/

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Wiki vs homepage

[Jenna Fox]

I agree wholly on the design front, and would like to contribute cartoony 
doodles and simple (not Backend Web Developer simple, but Designer Simple) web 
designs in vaguely _why's quirky fun style, if you guys are up for that. I'm 
currently rather more focused on Hackety Hack's web stuff, but in a couple of 
weeks when I get tired of drawing fruit bats and laser-breathing dinosaurs, 
Maybe camping would be a fun place to doodle? :)

If I forget, poke me @Bluebie.

@Judofyr - if you want to chat, I am a...@creativepony.com on msn/jabber these 
days. :)

Oh, and I don't know what the others think of this idea, but there is some talk 
of HetyH having a forum in the next refresh of it's website. How would you guys 
feel about being a part of that? I'm rather fond of the idea of reuniting the 
old _why community in some common shared space like that, though I'd fully 
understand if you guys feel it'd be a smelly situation to be a category in 
another project's forum.

Maybe instead - if you guys are pro-forum - there could be a website.. perhaps 
named something like 'Whyism', a special little cult of _why place for us all 
to hang out and talk about all his old projects, and our new stuff too. To keep 
the spirit of it all alive?

—
Jenna Fox
http://creativepony.com

On 09/07/2010, at 5:55 AM, Magnus Holm wrote:

> Hey guys,
> 
> Philippe had some interesting points about the website:
> 
> 1. Keep the home page simple with all content fitting within 1280 x 1024
> 2. Use a catchy design (need some help here)
> 3. Accentuate that Camping is about Ruby (maybe also include the ruby
> logo somewhere)
> 4. Have a brief note about the connection to _why and a link to a page
> explaining the history of Camping with further links to _why's other
> sites
> 5. Encourage people to try it by capitalizing on some of Camping's strengths:
> - Fast to learn - requires only basic Ruby skills
> - Much simpler than Rails but more structure than Sinatra/Padrino
> - Lightning fast and memory efficient allowing fast and efficient sites
> - Can evolve from simple file to organized directory structure
> - Can layer in more features later using persistence and choice of view 
> engines
> 6. How about using some kind of an animated (auto advancing) slideshow
> to highlight some of the benefits? See an example at:
> http://blog.monnet-usa.com/?p=276
> 7. How about a page on learning with a link to the book as well as a
> list of links for other tutorials or short explanations on key topics
> (e.g. how to do migrations, how to use include/extend, how to use
> different view engines, etc.)?
> 8. How about a page about plugins with some brief description of their intent?
> 9. I would love for us to include _why's cartoons in some of the sub pages ;-)
> 
> Now, the more I look at this list (and my own thoughts about the new
> camping site) I realize that we're talking about two different things:
> 
> * A site to attract new users
> * A site to inform regular users
> 
> It looks like my attempt (http://whywentcamping.judofyr.net/) tries to
> target the latter, while Philippe targeted the former
> (http://rubycamping.monnet-usa.com/). Both sites serves a purpose and
> I believe both are equally important.
> 
> --
> 
> Here's what I propose: We split the site into two parts. We turn what
> I've created into a wiki. Everyone are welcome to edit and add their
> own content.
> 
> Then we take Philippe's ideas/design/site and turn it into
> ruby-camping.com or whywentcamping.com or whatnot. It probably doesn't
> need to be more than a single page.
> 
> What'd ya think?
> 
> // Magnus Holm
> ___
> 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

Re: Wiki vs homepage

[David Susco]

I agree to the separation as well. A site that introduces camping with
a simple example/tutorial and that links to a wiki (with more advanced
stuff) and the mailing list is a good way to go about it.

Dave

On Thu, Jul 8, 2010 at 10:20 PM, Philippe Monnet  wrote:
> Yeah, I agree that it makes sense to have two sites, one to promote Camping
> and one to serve as the official reference. And a wiki would be very
> convenient for that.
>
> On 7/8/2010 1:55 PM, Magnus Holm wrote:
>
> Hey guys,
>
> Philippe had some interesting points about the website:
>
> 1. Keep the home page simple with all content fitting within 1280 x 1024
> 2. Use a catchy design (need some help here)
> 3. Accentuate that Camping is about Ruby (maybe also include the ruby
> logo somewhere)
> 4. Have a brief note about the connection to _why and a link to a page
> explaining the history of Camping with further links to _why's other
> sites
> 5. Encourage people to try it by capitalizing on some of Camping's
> strengths:
> - Fast to learn - requires only basic Ruby skills
> - Much simpler than Rails but more structure than Sinatra/Padrino
> - Lightning fast and memory efficient allowing fast and efficient sites
> - Can evolve from simple file to organized directory structure
> - Can layer in more features later using persistence and choice of view
> engines
> 6. How about using some kind of an animated (auto advancing) slideshow
> to highlight some of the benefits? See an example at:
> http://blog.monnet-usa.com/?p=276
> 7. How about a page on learning with a link to the book as well as a
> list of links for other tutorials or short explanations on key topics
> (e.g. how to do migrations, how to use include/extend, how to use
> different view engines, etc.)?
> 8. How about a page about plugins with some brief description of their
> intent?
> 9. I would love for us to include _why's cartoons in some of the sub pages
> ;-)
>
> Now, the more I look at this list (and my own thoughts about the new
> camping site) I realize that we're talking about two different things:
>
> * A site to attract new users
> * A site to inform regular users
>
> It looks like my attempt (http://whywentcamping.judofyr.net/) tries to
> target the latter, while Philippe targeted the former
> (http://rubycamping.monnet-usa.com/). Both sites serves a purpose and
> I believe both are equally important.
>
> --
>
> Here's what I propose: We split the site into two parts. We turn what
> I've created into a wiki. Everyone are welcome to edit and add their
> own content.
>
> Then we take Philippe's ideas/design/site and turn it into
> ruby-camping.com or whywentcamping.com or whatnot. It probably doesn't
> need to be more than a single page.
>
> What'd ya think?
>
> // Magnus Holm
> ___
> 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
>



-- 
Dave
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Wiki vs homepage

[Philippe Monnet]

Yeah, I agree that it makes sense to have two sites, one to promote 
Camping and one to serve as the official reference. And a wiki would be 
very convenient for that.


On 7/8/2010 1:55 PM, Magnus Holm wrote:

Hey guys,

Philippe had some interesting points about the website:

1. Keep the home page simple with all content fitting within 1280 x 1024
2. Use a catchy design (need some help here)
3. Accentuate that Camping is about Ruby (maybe also include the ruby
logo somewhere)
4. Have a brief note about the connection to _why and a link to a page
explaining the history of Camping with further links to _why's other
sites
5. Encourage people to try it by capitalizing on some of Camping's strengths:
- Fast to learn - requires only basic Ruby skills
- Much simpler than Rails but more structure than Sinatra/Padrino
- Lightning fast and memory efficient allowing fast and efficient sites
- Can evolve from simple file to organized directory structure
- Can layer in more features later using persistence and choice of view engines
6. How about using some kind of an animated (auto advancing) slideshow
to highlight some of the benefits? See an example at:
http://blog.monnet-usa.com/?p=276
7. How about a page on learning with a link to the book as well as a
list of links for other tutorials or short explanations on key topics
(e.g. how to do migrations, how to use include/extend, how to use
different view engines, etc.)?
8. How about a page about plugins with some brief description of their intent?
9. I would love for us to include _why's cartoons in some of the sub pages ;-)

Now, the more I look at this list (and my own thoughts about the new
camping site) I realize that we're talking about two different things:

* A site to attract new users
* A site to inform regular users

It looks like my attempt (http://whywentcamping.judofyr.net/) tries to
target the latter, while Philippe targeted the former
(http://rubycamping.monnet-usa.com/). Both sites serves a purpose and
I believe both are equally important.

--

Here's what I propose: We split the site into two parts. We turn what
I've created into a wiki. Everyone are welcome to edit and add their
own content.

Then we take Philippe's ideas/design/site and turn it into
ruby-camping.com or whywentcamping.com or whatnot. It probably doesn't
need to be more than a single page.

What'd ya think?

// Magnus Holm
___
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

Wiki vs homepage

[Magnus Holm]

Hey guys,

Philippe had some interesting points about the website:

1. Keep the home page simple with all content fitting within 1280 x 1024
2. Use a catchy design (need some help here)
3. Accentuate that Camping is about Ruby (maybe also include the ruby
logo somewhere)
4. Have a brief note about the connection to _why and a link to a page
explaining the history of Camping with further links to _why's other
sites
5. Encourage people to try it by capitalizing on some of Camping's strengths:
- Fast to learn - requires only basic Ruby skills
- Much simpler than Rails but more structure than Sinatra/Padrino
- Lightning fast and memory efficient allowing fast and efficient sites
- Can evolve from simple file to organized directory structure
- Can layer in more features later using persistence and choice of view engines
6. How about using some kind of an animated (auto advancing) slideshow
to highlight some of the benefits? See an example at:
http://blog.monnet-usa.com/?p=276
7. How about a page on learning with a link to the book as well as a
list of links for other tutorials or short explanations on key topics
(e.g. how to do migrations, how to use include/extend, how to use
different view engines, etc.)?
8. How about a page about plugins with some brief description of their intent?
9. I would love for us to include _why's cartoons in some of the sub pages ;-)

Now, the more I look at this list (and my own thoughts about the new
camping site) I realize that we're talking about two different things:

* A site to attract new users
* A site to inform regular users

It looks like my attempt (http://whywentcamping.judofyr.net/) tries to
target the latter, while Philippe targeted the former
(http://rubycamping.monnet-usa.com/). Both sites serves a purpose and
I believe both are equally important.

--

Here's what I propose: We split the site into two parts. We turn what
I've created into a wiki. Everyone are welcome to edit and add their
own content.

Then we take Philippe's ideas/design/site and turn it into
ruby-camping.com or whywentcamping.com or whatnot. It probably doesn't
need to be more than a single page.

What'd ya think?

// Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list