Re: Camping Free Ruby Hosting update and question
I'm not sure I understand the usefulness of the second and third server? Is it for redundancy? If I were running free hosting I'd be cautious of such things as I wouldn't want to give the users the impression I was going to be completely committed to keeping it online forever and having bulletproof reliability and so on.I guess I'd be focusing more now on building a community around it, so people can trade tips and help each other out. A forum or something like that I guess? — Jenna On Friday, 31 August 2012 at 10:02 AM, David C gurugeek wrote: Hello! Just a short update regarding the free hosting (I hope this is not too annoying but I received several emails from uses that saw this on the list so it could be interesting): we have now updated the system with more RAM and solid state drives. We have also removed the invitation key so everyone can apply at http://1.ai (provided that something that makes sense is written in the about you/motivation field. If you read this mailing list just note that and it will be fine - accounts are activated daily). The whole system is written in Camping + Bash and it was a bit of a challenge but also a lot of fun to learn the camping way to do things :) Yet this is just free hosting ..so what is new ? Well we were thinking to make the service more special by adding an automatic live sync of user space (and all the relevant apps) in 2 more servers. This will include the mysql database if needed so for example if your app is at campingapp.1.ai it will automatically be live synched in 2 separate servers so for example campingapp.1.ai campingapp.2.ai campingapp.3.ai and the main domain campingapp.dotgeek.org (http://campingapp.dotgeek.org) will automatically switch in case that a server becomes unavailable. What do you think about this ? It is probably not needed for most programmers that just want a space to try out things so we could also simply have a regular backup on S3 and similar services but it would certainly be something that, as far as I know, nobody offers ? Thanks and Best Regards David ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: _why documentary
One more thing - the text in the trailer misspells Why's name several times. Here are the preferred rules for naming him in writing, as told by Why: - Why The Lucky Stiff or why the lucky stiff - but never Why the lucky stiff or Why the Lucky Stiff - Why (for short, always capitalised like this) - _why (always lowercase) only if Why would be too grammatically ambiguous, like the start of a sentence, or for style. Generally people avoid the form 'Why', I suppose not wanting to think about if it's ambiguous in a particular context, but I think it's best to stick with the original intent. Surely too being confused just adds to the _mystery! :D — Jenna On Friday, 31 August 2012 at 10:53 AM, Kevin Triplett wrote: Hi all, I'm producing a short documentary on Why The Lucky Stiff which will be shown at RubyConf in Denver. I'd love to include details about camping in the film. If any core contributors or developers live in the Austin or Seattle areas and would like to participate, I'd greatly appreciate a chance to interview you regarding _why's code-as-art and other topics. Here's a trailer for the doc and a write up about it: http://youtu.be/Urw98i42HsI http://www.slackerwood.com/node/3115 I'm respecting the privacy of _why's creator and not attempting to contact him. The documentary is focusing more on the art and code of _why. Thanks for any feedback or help with this. Kevin Triplett Austin, TX ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Camping-list Digest, Vol 66, Issue 7
I'm in the inner sydney suburbs (terrace houses and all that), but Judofyr is over in Norway! Judofyr is probably the main contributor to camping in recent years - I haven't committed much code to the actual camping software, but I did do the web design everyone seems to hate at http://camping.io (especially windows users who can't read the menu text!) and serve as general evangelist type person. — Jenna On Friday, 31 August 2012 at 11:34 AM, Kevin Triplett wrote: Thanks for the encouragement and feedback, Jenna. I had no idea I misspelled his name but was aware of the two acceptable spellings (Why The Lucky Stiff and _why) -- must have made the mistake early in the project. I'll certainly expunge the defects and flog the wrongdoers. If there's anyone you know who produces video or has a decent camera in your area, I would *love* an interview with you or Judofyr, that would be fantastic. I'll see if I can find someone near you through my contacts -- where in Oz do you live? Thanks again! Kevin ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Feature: Inline templates?
What makes this better than a here doc? — Jenna On Wednesday, 15 August 2012 at 6:18 PM, judo...@gmail.com wrote: It's been implemented here: https://github.com/camping/camping/commit/407e2ddd441f438722828dc77d9094e0dea66143, but I don't think the current released version of Camping has it. Try `gem install camping --source gems.judofyr.net (http://gems.judofyr.net)` for a newer (pre-release) version. -Original Message- Re: Feature: Inline templates? From: gurugeek gurugeek...@gmail.com (mailto:gurugeek...@gmail.com) To: camping-list@rubyforge.org (mailto:camping-list@rubyforge.org) Sunday, August 12, 2012 at 5:15PM Hello I was searching inline templates on camping and found this old topic on the mailing list with the example from Magnus. I think it looks great and could be useful but I assume this was not implemented. Any plan to add this ? :-) Best Regards David Another feature! Inline templates: module App::Controllers get '/' do @title = My Perfect App render :index end end __END__ @@ index.erb Welcome to %= @title % What'd you think? Keep or throw away? It costs us 184 bytes at the moment. // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Feature: Inline templates?
Mmm so it is! Nice!
—
Jenna
On Thursday, 16 August 2012 at 1:10 AM, Magnus Holm wrote:
It's simpler. The alternative would be something like:
module App::Views
Index = Tilt['slim'].new { -EOF }
html
head
body== yield
EOF
end
module App::Controllers
def index
Views::Index.render(self)
end
end
This can also serve static files with correct MIME-type:
__END__
/style.css
* { margin: 0; padding: 0 }
// Magnus Holm
On Wed, Aug 15, 2012 at 4:44 PM, Jenna Fox a...@creativepony.com
(mailto:a...@creativepony.com) wrote:
What makes this better than a here doc?
—
Jenna
On Wednesday, 15 August 2012 at 6:18 PM, judo...@gmail.com
(mailto:judo...@gmail.com) wrote:
It's been implemented here:
https://github.com/camping/camping/commit/407e2ddd441f438722828dc77d9094e0dea66143,
but I don't think the current released version of Camping has it. Try `gem
install camping --source gems.judofyr.net (http://gems.judofyr.net)` for a
newer (pre-release)
version.
-Original Message-
Re: Feature: Inline templates?
From: gurugeek gurugeek...@gmail.com (mailto:gurugeek...@gmail.com)
To: camping-list@rubyforge.org (mailto:camping-list@rubyforge.org)
Sunday, August 12, 2012 at 5:15PM
Hello I was searching inline templates on camping and found this old topic
on the mailing list with the example from Magnus. I think it looks great and
could be useful but I assume this was not implemented. Any plan to add this
? :-)
Best Regards
David
Another feature! Inline templates: module App::Controllers get '/'
do @title = My Perfect App render :index end end
__END__ @@ index.erb Welcome to %= @title % What'd you think? Keep or
throw away? It costs us 184 bytes at the moment. // Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
http://rubyforge.org/mailman/listinfo/camping-list
___
Camping-list mailing list
Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
http://rubyforge.org/mailman/listinfo/camping-list
___
Camping-list mailing list
Camping-list@rubyforge.org (mailto: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: template, markaby question
See magnus's post at http://rubyforge.org/pipermail/camping-list/2010-August/001413.html for info on using the haml and erb support built in to Camping. Also note that you don't need to 'render' anything. You can just set @body to whatever string you want in your controller, or even return an IO or Array of stuff to turn in to strings. If you return an IO like a file or an a url opened with open-uri the server will automatically stream out the information. — Jenna On Tuesday, 14 August 2012 at 1:44 PM, gurugeek wrote: hello, I am trying to have some simple HTML to be used as a placeholder page for new servers users in a small camping application (basically with using the main site layout plus the current date and time :) )and I was wondering if the correct way is to rewrite the whole html using markaby or I should use the hack def layout text ' html inside where the only ruby code would be Today is '+Time.now.asctime+' ' or if there is any way that I don't know to have inline templates/use erb ? thanks a lot ! Best Regards David ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Camping 1 click deployment is live! 1.ai - alpha users welcome !
Heroku are the big tires, camping is the little wheels. They aren't a great fit. Heroku for example has a read-only file system and I believe no database in the free tier. This is a great little service we can build interesting things on. How about a remote server reloader? Streaming logs? Push notification stream server? View Source link for open web apps and demos. — Jenna Fox On Wednesday, 9 May 2012 at 1:30 PM, gurugeek wrote: On May 8, 2012, at 4:04 PM, Anthony Durity wrote: What are the limitations? I forgot to add these important limitations: - Presently No DB Support beside sqlite and couchdb if you use it via iriscouch or a similar service; - No professional support - so it is free but beside some help that I am willing to give to make sure that the service runs properly it cannot be compared with a professional service where you pay hence you can expect support In terms of benefits thou the app should run considerably faster than on the free tier of heroku because of the non-virtualization and the SSD hard drives - in my tests sqlite and all in general ix x 5 times than in a traditional HD or on EC2. The idea is to get people to learn and use camping and deploy it /see their app live immediately. It should be a good learning tool but not to run a professional application with clients etc. or where you expect a lot of support. ___ 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: Camping 1 click deployment is live! 1.ai - alpha users welcome !
A lot of repos for websites have dots in them, should fix it to support anything github can support. — Jenna On Monday, 7 May 2012 at 10:30 AM, gurugeek wrote: On May 7, 2012, at 2:23 AM, Jenna Fox wrote: Things: 1) It'd be super cool if the user types in their email address as the username if it still works Yes this should be easy to do - could put both I think email or username 2) I wonder what I'm doing wrong? I enter in bluebie/whywentcamping.com (http://whywentcamping.com) in the github repo name and it says my url contains invalid characters? I think the check in the script doesn't allow a repository to have a points inside it ..is it very common ? Can fix this but if you want to try in the interim just use any repo without a . on it :) Thanks again for testing this out David — Jenna On Sunday, 6 May 2012 at 10:41 AM, gurugeek wrote: Hello Campers! I am happy to announce that the camping 1 click deployment is now available at http://1.ai (http://1.ai/) The platform has been coded with camping (with some help from bash for the backend scripts) and it seems to work very well. We have spent some time to get sure that it would be secure and easy to use. After working on an easy and secure way to upload/manage files online etc. we have found an easier solution: fetch a github repository with a camping application and - with one click -deploy it online at yourname.1.ai So how does this works ? 1 - you signup 2 - after logging in you simply fetch your camping application from a github repository there is a sample hello world available at https://github.com/gurugeek/0ai and this is also explained in the app admin page 3 - after fetching (provided that this is a valid camping app and has a valid config.ru (http://config.ru/) file) your application will be live. The admin panel has all these instructions and if you try to fetch a non-camping application from a github repository it will return the relevant error. The system supports private repositories too (this said I wouldn't run something very secret and private on it!) but you would need to authorise the github user 1ai to access your private repository. Github has a lot of wonderful features so I feel that this was the best solution without re-inventing the wheel. It is probably the fastest and easiest way to get your camping application up and running. Each application is securely isolated but all this is running in a traditional dedicated server (no virtual/cloud/droids) are employed. This should enhance the application performance. The server is also using only SSD (solid state drivers) that are not yet available in most of cloud providers (EC2, Rackspace cloud). I really appreciate your testing and comments so please go on and launch your shiny Camping app at http://1.ai (http://1.ai/) ! A small caveat: The aim of this service is (hopefully) to promote camping (perhaps next with a programming contest with some cool prizes) but it is obviously not meant to replace a traditional hosting in the sense that there will be no tech support offered and the service is provided without any warranty. This doesn't mean that is not good enough to run any of your fancy Camping apps - just that you should not expect this to replace any professional hosting. Note on Databases: -If you have an sqlite database in your github repository it should work just fine. If it works for you locally it should work fine on http://1.ai (http://1.ai/) after the github fetch -If you want to use CouchDB you can do it with the wonderful Chill (https://github.com/Bluebie/chill) and http://www.iriscouch.com/ (which is free for small apps/usage). Once you have your CouchDB on iriscouch you simply connect to it from your camping app, fetch the data etc. I do look forward to your comments and welcome any question you might have! Best Regards David ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: mab advice
So essentially you want the 'label' string inserted verbatim as html code,
rather than as plain text?
li { a(:href = link) { label } }
In markaby and presumably mab, strings passed as arguments are escaped, and
html is inserted as bodies of elements via blocks - you can build that body
either by calling more markaby functions inside the block, or by simply
returning the fully formed html contents as a string, as above.
Hope this helps!
—
Jenna
On Saturday, 5 May 2012 at 12:24 AM, Dave Everitt wrote:
I have a simple helper function containing this to spit out a list of
links from a hash:
...
links.each_pair do |label, link|
li { a label, :href = link }
end
...
my hash elements are (obviously):
'Link label' = 'http-link',
I'd now like to add a 'strong' tag around some of the text in the
labels (which I didn't foresee), but the tag would be within the hash
key. Ideas? Warnings?
DaveE
___
Camping-list mailing list
Camping-list@rubyforge.org (mailto: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
ChillDB License
A few of you sounded interested in using it. I haven't explicitly put a software license on it, so I guess it's not technically FOSS yet. What licenses are good? BSD? Public Domain? — Jenna ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: definitive markaby
Mab is going to be the new one going forward. If I remember right, the reasons for this were: 1) Markaby isn't very well maintained these days 2) Markaby is all about xhtml, which is totally irrelevant to the modern web. 3) Markaby doesn't explicitly have a license allowing us to do stuff to it. I think that's what the deal was. Maybe this has changed since then, maybe not. For a time new installations of camping wouldn't work, due to Markaby becoming incompatible with an update to it's dependancy Builder. — Jenna On Wednesday, 2 May 2012 at 10:15 PM, Dave Everitt wrote: I'm compiling Camping links... please can someone refresh my memory: how does this: https://github.com/igravious/markaby relate to this: https://github.com/camping/mab ? DaveE ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: ChillDB License
This is very helpful! I don't really mind though. Maybe public domain is best. I'm not a big believer in copyright. — Jenna On Wednesday, 2 May 2012 at 10:57 PM, Anthony Durity wrote: Hey there, BSD uses full copyright, it's like saying all rights reserved. Public domain means no rights reserved, it's not a FOSS thing - FOSS means generally an accepted free software license or and accepted open-source license. Public domain isn't a license per se. Licenses like the GPL-style licenses force the code to remain open if an entity modifies the source _and_ redistributes the subsequent binaries. BSD does not enforce this. BSD is thus sometimes seen as more corporate-friendly. Depending on your notion of freedom (freedom from something or freedom to do something) you may feel that BSD-style is freer or GPL-like is freer. If you want to have a FOSS license then normally go with (L)GPL2 (L)GPL3 Apache MIT BSD http://en.wikipedia.org/wiki/List_of_FSF_approved_software_licences If you want to free it to the four corners of the earth but not have it FOSS then public domain it - certain high profile pieces of software are public domain (Sqlite I think?) but not many. Hope that helps. Apologies if you already knew all this. On Wed, May 2, 2012 at 1:34 PM, Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) wrote: A few of you sounded interested in using it. I haven't explicitly put a software license on it, so I guess it's not technically FOSS yet. What licenses are good? BSD? Public Domain? — Jenna ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: definitive markaby
Yes. — Jenna On Wednesday, 2 May 2012 at 11:14 PM, Dave Everitt wrote: thanks - a compact but completely-formed answer. So 'mab is the Camping-specific markaby' would be an accurate statement? - DaveE Mab is going to be the new one going forward. If I remember right, the reasons for this were: 1) Markaby isn't very well maintained these days 2) Markaby is all about xhtml, which is totally irrelevant to the modern web. 3) Markaby doesn't explicitly have a license allowing us to do stuff to it. I think that's what the deal was. Maybe this has changed since then, maybe not. For a time new installations of camping wouldn't work, due to Markaby becoming incompatible with an update to it's dependancy Builder. — Jenna On Wednesday, 2 May 2012 at 10:15 PM, Dave Everitt wrote: I'm compiling Camping links... please can someone refresh my memory: how does this: https://github.com/igravious/markaby relate to this: https://github.com/camping/mab ? DaveE ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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
Gone a little crazy
So, I went a little crazy this weekend and did a whole bunch of things: * camping.io now renders properly in Chrome (yay! why didn't anyone tell me this was broken? evolving web standards are annoying!) * I tidied up some issues and commented on heaps of things on https://github.com/camping/camping/issues * I patched a readme to not talk about features we removed from The Camping Server * I created extensive documentation for chill - my couchdb abstraction. http://creativepony.com/chill/rdoc/ChillDB.html * I added bulk commit and delete support to chill - which should improve performance quite a bit * I added ruby views support to chill - but I haven't tested this yet. All these things seem vaguely related to camping (at least to me). Lets talk about the website! — Jenna ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
The Website
So here we are, talking about the website again. Here's my thinking: David Costa's nearly got that neat camping app hosting thing working, which is amazingly awesome and we love him so much! People have all sorts of interesting ideas for things the camping site could do and have - lists of apps made in camping, wikis, forums, live chats where you're all a little spider in a sink and you can run around with your mouse and say things, text adventures, screencast theatres, interactive tutorials, book viewers, etc. What if we all just make a cool thing, and put it on David's cool hosting, and then we can all just run our own little sections of camping, like a little tent village with lots of homes which all have their own unique flavour. We could sort something out to have unified navigation menus, and have a simple app (or static page) to serve as the homepage, acting more as a gateway in to these other apps than anything else. We would be in charge of our own sections and it'd be awesome because we're all great at everything we do and we're all really great people! My hypothesis is many things aren't getting done with the website because we all just really can't be bothered getting consensus on the mailing list. We're impulsive creative people who just want to burst with energy and do something immediately without having to talk about it and justify it first. Consensus Democracy has worked great for the framework but maybe not for the site. What do you think? Can I get a consensus on this? — Jenna ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Gone a little crazy
Yeah I'm not even going to attempt that one. Opera is way out of my league. If you know how to fix it, I'd love the help, otherwise I'm all for opera's plan to pretend to be webkit. Maybe there's some way we can detect it and show opera a simpler website? — Jenna On Sunday, 29 April 2012 at 9:04 PM, Bartosz Dziewoński wrote: camping.io (http://camping.io) is still badly broken for me on Opera 11.62, Windows XP. Screenshot: http://i.imgur.com/7YZQf.png (These weird light-yellow bits aren't there, something went wrong with my screen capture tool, I guess.) -- Matma Rex ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Gone a little crazy
Fixed url for Opera. As for text rendering, so long as it's readable, I don't
mind if it's ugly. Happy to let the Opera team fix Opera's bugs.
—
Jenna
On Sunday, 29 April 2012 at 10:22 PM, Bartosz Dziewoński wrote:
Well, the background doesn't display because the path to the
background image (paper.png) is given incorrectly...
-webkit-border-image: url(paper.png) 75 30 50 30 stretch stretch;
-moz-border-image: url(paper.png) 75 30 50 30 stretch stretch;
-o-border-image: url(http://whywentcamping.com/img/paper.png;) 75
30 50 30 stretch stretch;
You should also ensure that the text is at least readable without the
background - a rule like #subwrap*{background-color:beige} will do
the trick (although will hide the fine texture of paper.png - to avoid
this, create another small image to set as background to #subwrap*
containing just the texture).
I don't know why the fonts don't display, but I'll try looking into it.
-- Matma Rex
2012/4/29 Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com):
Yeah I'm not even going to attempt that one. Opera is way out of my league.
If you know how to fix it, I'd love the help, otherwise I'm all for opera's
plan to pretend to be webkit. Maybe there's some way we can detect it and
show opera a simpler website?
—
Jenna
On Sunday, 29 April 2012 at 9:04 PM, Bartosz Dziewoński wrote:
camping.io (http://camping.io) is still badly broken for me on Opera 11.62,
Windows XP.
Screenshot: http://i.imgur.com/7YZQf.png (These weird light-yellow
bits aren't there, something went wrong with my screen capture tool, I
guess.)
-- Matma Rex
___
Camping-list mailing list
Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
http://rubyforge.org/mailman/listinfo/camping-list
___
Camping-list mailing list
Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
http://rubyforge.org/mailman/listinfo/camping-list
___
Camping-list mailing list
Camping-list@rubyforge.org (mailto: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: The Website
Most excellent news! :D — Jenna On Sunday, 29 April 2012 at 10:03 PM, Isak Andersson wrote: This would be great! I think I'm gonna host a development blog for the game I'm working on David's hosting service. But that will be a while from now so I'll create something else that's cool. PS. I'll work my ass off to have the first screencast done on tuesday! Cheers! Isak Andersson Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) skrev: So here we are, talking about the website again. Here's my thinking: David Costa's nearly got that neat camping app hosting thing working, which is amazingly awesome and we love him so much! People have all sorts of interesting ideas for things the camping site could do and have - lists of apps made in camping, wikis, forums, live chats where you're all a little spider in a sink and you can run around with your mouse and say things, text adventures, screencast theatres, interactive tutorials, book viewers, etc. What if we all just make a cool thing, and put it on David's cool hosting, and then we can all just run our own little sections of camping, like a little tent village with lots of homes which all have their own unique flavour. We could sort something out to have unified navigation menus, and have a simple app (or static page) to serve as the homepage, acting more as a gateway in to these other apps than anything el se. We would be in charge of our own sections and it'd be awesome because we're all great at everything we do and we're all really great people! My hypothesis is many things aren't getting done with the website because we all just really can't be bothered getting consensus on the mailing list. We're impulsive creative people who just want to burst with energy and do something immediately without having to talk about it and justify it first. Consensus Democracy has worked great for the framework but maybe not for the site. What do you think? Can I get a consensus on this? — Jenna Get the best selection of online sites here. Click Here to check them out! http://click.lavabit.com/ki3fjboh1at1j78grodt3ognyxtbqnur6gypm4ruhg1jdusgqdzb/ ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Camping + Couch DB
Glad you like it! Chill isn't totally feature complete, but it has the important bits I think. If you ever find yourself needing extra bits I'd love to bulk it out some more - I just haven't had a use for it lately and I've not wanted to design APIs I'm not using myself. Much of the choices were made better by dogfooding (http://en.wikipedia.org/wiki/Eating_your_own_dog_food), I feel. I've been taking a bit of a break from programming lately. I'm learning にほんごそしてひらがな as a productive way to take a break from all this highly logical stuff! — Jenna On Thursday, 26 April 2012 at 9:09 PM, Dave Everitt wrote: Hi Nokan I'm a professional newbie (simply because I use and teach a wide range of stuff and only go deep when I have to :-) As I'm sure you're aware, as an embedded lightweight database SQLite makes an easily-managed default setup (as in Camping... and Django, and even within OS X and, of course... RoR), but if you need a client- server database I'd say that's beyond the test server remit and would be a whole other setup/maintenance layer for David :-) SQLite is fine for me simply because I don't need anything bigger, and I can include the db file in a git repo (don't know yet if that's easy with CouchDB - anyone?). But Couch would be my choice for on/offline data sync, and I'd probably use Jenna's chill (https://github.com/Bluebie/chill) and also revisit Knut Hellan's article from 2009 (http://knuthellan.com/2009/03/08/camping-with-couchdb/ ). DaveE Hi, In a previous thread I was declared as a newbie end user, now I'll behave like that :) If I'll use the hosting service, I'll want to be able to use mysql and not sqlite, and other experimental solutions. You can say that this is silly of me, but, as an end user, I have the right to be silly. BTW I have bad experience with sqlite. It can happen that the database becomes corrupted somehow, maybe because of not properly handled concurrent accesses, or a ctrl- c in a bad moment, I don't know. And mysql is faster too. As a silly end user I would prefer a separately existing permanency layer. This is not a problem for active record, so I really don't get it why not to use it. (It would be enough to have one database for all the users and let the databasename_tablename structured tablenames solve the rest. Actually the users don't need to know where is the data stored and how, just use the ActiceRecord API, but they need to know that it's fast enough and the data is securely stored.) I'm sorry, I know I was not really constructive... ...end users are always silly... ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Camping + Couch DB
So far as uploading a couchdb to a git repository - You could probably find the files somewhere in your system and do that, but it sounds like a bad idea. Better: use wget to download the all_docs page, backing up all the documents on that database in to a single file. Then you can restore it by wget posting it to a new server, effectively doing a bulk commit. Quick, easy, readable text file containing json and newlines IIRC. It might take some tinkering to get it to include your design documents too, but if you're chillin' you can just rerun the file which updates them to recreate those. — Jenna On Thursday, 26 April 2012 at 9:09 PM, Dave Everitt wrote: Hi Nokan I'm a professional newbie (simply because I use and teach a wide range of stuff and only go deep when I have to :-) As I'm sure you're aware, as an embedded lightweight database SQLite makes an easily-managed default setup (as in Camping... and Django, and even within OS X and, of course... RoR), but if you need a client- server database I'd say that's beyond the test server remit and would be a whole other setup/maintenance layer for David :-) SQLite is fine for me simply because I don't need anything bigger, and I can include the db file in a git repo (don't know yet if that's easy with CouchDB - anyone?). But Couch would be my choice for on/offline data sync, and I'd probably use Jenna's chill (https://github.com/Bluebie/chill) and also revisit Knut Hellan's article from 2009 (http://knuthellan.com/2009/03/08/camping-with-couchdb/ ). DaveE Hi, In a previous thread I was declared as a newbie end user, now I'll behave like that :) If I'll use the hosting service, I'll want to be able to use mysql and not sqlite, and other experimental solutions. You can say that this is silly of me, but, as an end user, I have the right to be silly. BTW I have bad experience with sqlite. It can happen that the database becomes corrupted somehow, maybe because of not properly handled concurrent accesses, or a ctrl- c in a bad moment, I don't know. And mysql is faster too. As a silly end user I would prefer a separately existing permanency layer. This is not a problem for active record, so I really don't get it why not to use it. (It would be enough to have one database for all the users and let the databasename_tablename structured tablenames solve the rest. Actually the users don't need to know where is the data stored and how, just use the ActiceRecord API, but they need to know that it's fast enough and the data is securely stored.) I'm sorry, I know I was not really constructive... ...end users are always silly... ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Camping + Couch DB
Sorry correction - the argument to ChillDB for setting your password is pass:
'hackerbats', not password: 'hackerbats'. Silly me! Maybe chill should accept
both!
—
Jenna
On Friday, 27 April 2012 at 1:47 AM, Jenna Fox wrote:
Sure. To connect chilldb using a username and password:
ChillDB.goes :CakeTown, user: 'david', password: 'hackerbats'
To connect it to a remote server:
ChillDB.goes :YellowBrickRoad, host: 'davidcosta.camping.io
(http://davidcosta.camping.io)'
You can combine those to level up, and even add a port setting if you like!
To make a database with some users you could do this:
ChillDB.goes :FunkyTown
# make a little template for our citizens - this doesn't do anything to the
server, it's just in ChillDB's memory
FunkyTown.templates(
# creates a citizen template - note that an extra property - kind:
'citizen' is implied unless you specify otherwise, for convenience when
writing views
citizen: {
name: unknown,
email: nil
}
)
# add a design with a view to get citizens via their emails
# you only need to run this once to setup the site - it stores it to the
server
# it doesn't matter if you run it whenever you restart the servers though -
it just means couchdb has to recompute the views, which maybe a bit slow on
sites with lots of documents
FunkyTown.design(:citizens).views(
# for all the documents which have a 'kind' value of 'citizen' and have an
email set, we list them in the by_email view
by_email: %q(function(thing) {
if (thing.kind == citizen thing.email) emit(thing.email, thing);
})
)
# add some people
people = ['david', 'daniel', 'nokan', 'dave', 'jenna', 'magnus']
people.each do |person|
FunkyTown.template(:citizen).merge!(name: person, email:
#{person}@camping.io (http://camping.io)).commit!
end
# lookup magnus via his email
magnus = FunkyTown.template(:citizens).query(:by_email, key:
'mag...@camping.io (mailto:mag...@camping.io)')
couchdb is a simple thing, so if you need the ability to select all users,
you do that by making another view which lists all the documents where
document.kind == 'citizen' for this example. There's no magic way to do those
sorts of queries - you need to tell the database in advance. CouchDB does
actually have a facility for creating 'temporary views' - but chill doesn't
implement it and couchdb guys explain in harsh words in their docs that it's
not for use in production environments - it's just for playing around testing
views before you're sure what you want. CouchDB has a nice little web
interface (like a pretty and simple phpmyadmin) built right in where you can
try out views like that, so I didn't see the need to have it in chill.
CouchDB also has a special all_docs thing you can load, which is basically a
view with everything in it. This way you can just do normal select, find,
map, reduce, etc, with normal ruby arrays and things, if your data set is
small enough that you don't need all of this stuff cached in the database
itself.
Chill doesn't do conflict validation, and it shouldn't. CouchDB doesn't work
that way. You don't avoid trouble by validating that a user doesn't exist
then creating them, you avoid trouble by making sure that when you look up a
user and find there is two of them, you have some way to merge them or flag
it up for an admin to fix. Once you have more than one database server or
more than one web server process, you can't depend on the database keeping
things like that sane for you. You could check the user doesn't exist yet,
then another server could check, create the user, then you create the user
also, and now there's two of them. It's good for the web ui to try and block
this stuff - it just can't be guaranteed without making huge sacrifices to
concurrency. As CouchDB can run in a p2p structure (masterless) there's no
single database you can talk to who can make promises like that, and
databases can even run disconnected from each other then sync up later - neat
for mobiles and the likes.
—
Jenna
On Friday, 27 April 2012 at 12:37 AM, david costa wrote:
Hello Jenna,
I like chill too !
Is it possible to have a simple example with db connection (I see you have
this on ChillDB::Database but just wanted to get something simple to cover
the username/password and/or remote couch server with a different URL than
localhost)
and again a very simple usage to keep a database of users and a map
reduce/view to select a user by email, select all users and perhaps
validate if a user already exist ? :P
Thanks
David
On Thu, Apr 26, 2012 at 2:55 PM, Jenna Fox a...@creativepony.com
(mailto:a...@creativepony.com) wrote:
Glad you like it! Chill isn't totally feature complete, but it has the
important bits I think. If you ever find yourself needing extra bits I'd
love to bulk it out some more - I just
Re: framework size, forking etc.
I think the trouble with streaming over the rack interface is that it's confusing. I'm fairly good at ruby, but I'm not entirely sure how it would even work. I guess I need to run my app in a threaded web server, running every request in it's own thread? Then inside the each iterator in the response object it just sleeps until it's got more data, using some sort of global message queue object to organise messaging between all the different threads? What if I'm deploying to passenger? what about fastcgi? Does that mean one ruby process per stream? Right now I have a few thins running with a ngynix proxy. Will the proxy be okay with sending in multiple concurrent requests in to the thins or will it need to have a process per user? It's well and truly away from being the simple rack thing everyone liked. It only gets worse when you start wanting websockets - which don't fit the rack model at all (and rightly so! but they still need to be supported) In the end what I really want is to be able to return a Rack::Stream.new as the response, which will do the each magic and deal with the web server in some way where it's the server's responsibility to make sure it works - none of my concern, and where I can keep around a reference to that Stream object and send it messages. It's actually a pretty simple problem to solve, except for getting the different ruby servers to implement one common standard on how to deal with ruby apps which have lots of long running connections open. Maybe it could be made to work somewhat okay, but I cannot imagine in my head having ten thousand sleeping threads open waiting for something to stream out is going to be very performant. There's also the Fibers and Continuations stuff which is probably about as close as we can get to a good work around for a completely artificial problem created by the rack interface. — Jenna On Thursday, 19 April 2012 at 12:59 AM, cdr wrote: # Sorry for ranting a little all very interesting # even the unabridged code is far from readable # I think my attraction as a novice to Camping was for its clarity these two things are inconsistent? but this brings it around: # I'm being incoherent # 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 yep, to me a 'model' at request time is always based on inside some CSV or JSON file, an Email, an IRC log, something curl piped to a file in a script run by cron the notion that you'll be writing new ruby Classes for each class of resource in th datamodel, and new routes, and migrations to prime DB tables seems fundamentally crazy to me, and with rails' mindtrain it was copied on sinatra,camping,merb,ramaze # I've mostly moved onto working in Python i tired of ruby around 2007 after writing the webserver i actually wanted, rather than the framework i didnt want. it is baroque for the possibility of a runtime type-error failure to even exist. with type-inference, your Haskell or OCaml code is not more verbose than Ruby. i still maintain my webserver since it works fine but i'd never start a new project in ruby at this point # their community actually brags about it, and makes a point of how much easier your life could be if you use it the Rails community did this quite a bit too. all the alphabloggers like Ezra/Tom/court8nay and countless HN/Reddit mobs. i think it ties into human psychology of self-apprised status somehow, but it is just silliness, like obsessing about getting into a VIP Room at a club 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. Rack is really simple, in goes a Hash of request environment, out goes a status-number, response environment + body. essentially thats what HTTP is. after making handlers for ebb, flow, mongrel, it was nice to delete all that code and just write a rack handler - they were all so similar anyways as for streaming, i was able to trivially implement 'tail -f' using rack [0] am interested in hearing what your thoughts on how Rack should change [0] http://gitorious.org/element/element/blobs/master/ruby/W/tail.rb ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: framework size, forking etc.
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 (mailto: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 (mailto: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: Markaby xhtml_strict
Urgh. I just turn the validation in markaby off pretty much all of the time - like strictly typed languages, I find it gets in my way more often than it helps me find errors. Instead of using the xhtml_strict macro you could do it yourself: self !DOCTYPE whatever blah blah\n html lang = 'lc', xml:lang = 'lc' do ... end Though if you're going down to this level, why not switch over to html5? Everything you can reliably do in xhtml 1.0 is also available in html5, and the html5 doctype is simpler, while still supporting browser features using the same syntaxes you're familiar with in addition to newer compact versions. The html5 doctype is this: self !DOCTYPE html\n HTML5 will become the default in a future edition of camping, as it supersedes the xhtml standard and provides compactness benefits and useful new features. Further, xml:lang is not necessary when using html5 syntax - lang is sufficient. Have you also considered the possibility of serving the language as a header? Content-Language is a http header of similar effect, which you could even set in your markaby templates via @headers['Content-Language'] = 'lc' — Jenna On Monday, 16 April 2012 at 10:04 PM, Nokan Emiro wrote: Hi, I use this in Markaby to generate an html tag, but I need to add lang=lc and xml:lang=lc (lc != :en). However xhtml_strict does not accept arguments. :-/ Why not? And then how should I generate XHTML1.0 Strict docs in other languages? (I always feel foolish when face with such trivial problems...) u. ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: http_referrer
O_o I think the extra character is worth it. — Jenna On Monday, 16 April 2012 at 9:40 AM, david costa wrote: Ah well the is not on fcgi but passenger :) I would say that most of the serious ruby/rails hosting now offer passenger as an option so shouldn't limit your application portability. On Sun, Apr 15, 2012 at 11:41 PM, Dave Everitt dever...@innotts.co.uk (mailto:dever...@innotts.co.uk) wrote: Understood about compatible - this is David's Camping server, and I'm experimenting with QUERY_STRING in the URL and various other env vars - DaveE On Sat, Apr 14, 2012 at 10:38, Dave Everitt dever...@innotts.co.uk (mailto:dever...@innotts.co.uk) wrote: Haha! How did you get Spock on board... :-) I must admit I'm a little confused about the sytnax for environmental variables, because as well as @env[HTTP_REFERER] this also works: ENV['SCRIPT_NAME'] For a test I just used it like this: ENV['SCRIPT_NAME'].scan(/\w+\.\w+$/) to get the Camping file's name (with whatever file extension rb, rbx, cgi) instead of using __FILE__ The only reason ENV['HTTP_REFERER'] works for you is that you deploy on (Fast)CGI. You should only depend on @env if you want your app to be compatible with other servers. ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Camping's URL mapping system
An A4 piece of paper has a little over 9kb of data storage if storing in binary at 300dpi — Jenna On Saturday, 14 April 2012 at 1:09 AM, Dave Everitt wrote: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Camping's URL mapping system
On the other hand, Camping is already far too big to fit entirely in a QR code. It would take as many as TWO QR codes to store camping in it's entirety. — Jenna On Saturday, 14 April 2012 at 1:40 AM, Jenna Fox wrote: An A4 piece of paper has a little over 9kb of data storage if storing in binary at 300dpi — Jenna On Saturday, 14 April 2012 at 1:09 AM, Dave Everitt wrote: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Camping's URL mapping system
The problem is basically this: Sometimes you want to reference static files, and other components of your site. I have a Gallery app mounted at http://creativepony.com/gallery/ and it causes me all sorts of trouble. Often times to reference static files I end up needing to use /../ in URLs inside of views and controllers, which webservers surprisingly correctly translate in to the wanted files, most of the time. Other times I want to reference other camping apps mounted in the same server instance via a rack URLMap. I know as I say this someone will paste a function I can redefine with some boggling ultracompressed camping code inside, where every variable is a letter - but I have work arounds which work. The trouble is that hacking about like this just isn't fun. In my opinion Camping needs in it's core static file serving, catchall before/after methods for controllers, and I have no idea how, but we need to fix the insanity which is the (self / arg) thing being applied to all src and href values in markaby templates. It's a great idea and I love it when it works, but it's so often a leaky abstraction for me, and when it leaks, there's no clear solution! — Jenna On Thursday, 12 April 2012 at 11:35 PM, Dave Everitt wrote: In another post, Jenna said: I have some trouble with Camping's URL mapping system - so much so I'm considering sinatra for my next ruby web project I just wanted to know what the trouble was, and if/how it might/could/ can't be addressed, so started a new thread. DaveE ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Camping's URL mapping system
bin/camping is great but it's not usually a good way to deploy an app on a server - it tends to be more for development. Putting functionality in to bin/camping which belongs in camping core is like wearing a backpack filled with hydrogen while having your weight checked. 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. I think we should have a little line you write right in to your app file which says where you keep your files. Something like MyApp.files = 'public'. Maybe that's the default. 'just redefine service' isn't a good solution no matter how many times you post it on this list. I shouldn't need to lookup any references or archaic mailing list archives to do something so simple in a new project. For the local file urls thing, I propose a breaking change (eg: camping 3.0) the addition of a method named local() # for now it looks like this: def local arg self / arg end and the removal of magic (self / arg)ification of href and src attributes in markaby templates. local() should eventually talk to MyApp.files and the file serving feature so they can all work together nicely - all the code for that should be in one place, maybe in one class. Using local() adds some interesting opportunities too. It'd be really easy to modify local do to other stuff, like load your files from a database, or make urls which reference files by their inode number instead of their file path, or have it return data uris, or have it generate Amazon S3 urls with one time keys in them, or include the file's mtime in the url, allowing the server to specify month-long cache durations while apps instantly pick up changes, making them feel super responsive. One more thought - on file serving, I think it'd be nice if the default was that local files are served out of /files/ url rather than just being at the app's root level. I know this would be controversial: It would be really clear to beginners, and if someone writes img(src: 'files/blah.png') camping can raise a warning explaining the img(src: local 'blah.png') syntax. It also means web servers would need to be explicitly configured to duplicate that behaviour at a lower level - a simple quick camping setup would always serve files through camping, making debugging easier and applications more reliably portable. People who need the performance boost of doing it at the web server level can do that - it just wont happen by default. Deployment is one of the biggest hassles we face - this may help. — Jenna On Friday, 13 April 2012 at 12:26 AM, Magnus Holm wrote: On Thu, Apr 12, 2012 at 15:59, Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) wrote: The problem is basically this: Sometimes you want to reference static files, and other components of your site. I have a Gallery app mounted at http://creativepony.com/gallery/ and it causes me all sorts of trouble. Often times to reference static files I end up needing to use /../ in URLs inside of views and controllers, which webservers surprisingly correctly translate in to the wanted files, most of the time. Other times I want to reference other camping apps mounted in the same server instance via a rack URLMap. I know as I say this someone will paste a function I can redefine with some boggling ultracompressed camping code inside, where every variable is a letter - but I have work arounds which work. The trouble is that hacking about like this just isn't fun. In my opinion Camping needs in it's core static file serving bin/camping should serve public/ , catchall before/after methods for controllers, module App def service(*) p :before super ensure p :after end end and I have no idea how, but we need to fix the insanity which is the (self / arg) thing being applied to all src and href values in markaby templates. It's a great idea and I love it when it works, but it's so often a leaky abstraction for me, and when it leaks, there's no clear solution! I agree, although I don't have any elegant solutions… ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: sites powered by Camping
I don't think we should ever consider pagerank in decision making. Sounds like a nice idea otherwise tho. Does anyone want to maintain a page like that? — Jenna Fox On Wednesday, 11 April 2012 at 9:37 PM, Nokan Emiro wrote: Hi List, What about creating a section on the Camping site, where you list and link sites that were built using Camping? Of course just those ones that are good enough. It would show the public that it's a working framework, so it's good for the community. On the other hand it's good for the linked page too, it gets visitors and a bit boost of page rank. u. ___ 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: lighttpd + fastcgi + camping
Camping is a rack app. Check out the rack docs for info on how to mount it as any kind of server interface. — Jenna Fox On Saturday, 7 April 2012 at 1:26 AM, david costa wrote: Hello all, I am running in some little stumbling blocks with passenger as a multi user environment (the most problematic feature is that, once you setup a sub-domain passenger wants you to declare on nginx every app running on that nginx server which is not ideal to add apps on the fly and / or if a user wants to run 2 apps from his space) so I was thinking about a more drag a drop / one line command line deploy (even multiple camping apps and not just one) and I would like to test camping with lighttpd + fastcgi. I assume that this would allow a user to run as many camping application as he wants (space permitting) without having to reconfigure lighttpd each time an application is added correct? Question: on the examples I can only find a camping fcgi dispatcher for apache. Do you have any dispatcher that would work on lighttpd or should I use a generic ruby dispatcher like http://pallas.telperion.info/ruby-cgi/ ? Thanks David ___ 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: Update book
Let me know exactly what text you want replaced with exactly what, and I'll make that change now. — Jenna On Tuesday, 3 April 2012 at 7:07 PM, Isak Andersson wrote: Hello. I think we should update the book a little bit. On the part of migrations we use def self.up and def self.down this method actually gave me errors for some reason. But anyways, it should be updated to def self.change anyways because that's the modern way of doing it. I tried doing this myself but for some reason I don't get the gh-pages branch when cloning camping.io (http://camping.io) so Jenna or someone will have to do it instead! - Isak Andersson ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: dead easy deployment / Camping on the fly
Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software. Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well. Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets). Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere. — Jenna On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: Wonder if Google might help getting camping to run on app engine? On 1 April 2012 10:03, david costa gurugeek...@gmail.com (mailto:gurugeek...@gmail.com) wrote: Ah I forgot you can compare camping running on thin here http://run.camping.io:3301/ vs passenger at http://run.camping.io apparently db has some problems with fusion passenger (see http://run.camping.io create HTML page and test HTML page. The same code on thin works just fine... umhh oh no don't feel like more debugging ): On Sun, Apr 1, 2012 at 9:51 AM, david costa gurugeek...@gmail.com (mailto:gurugeek...@gmail.com) wrote: Okay :D after many many hours of testing I am settled for nginx and passenger. live at http://run.camping.io/ I did try every apache combination (with passenger, with cgi, etc. etc.) as is simply not really working fine. I tried some other obscure web servers too but apparently this seems to work fine for now :) other servers would run the app as CGI or FastCGI. I am not worried about speed just ease of deployment and nginx with passenger seems to do the job for now. The alternative is nginx as reverse proxy but as Jenna rightly pointed out it would spawn a lot of thin instances that might or might not be used. I did throw the sponge at Webdav on apache. It doesn't work as expected and not with all clients. It seems more suitable to store quick files than something else. Can try tomorrow with nginx but perhaps it would be nicer to have a quick camping hack to upload a file etc. but you can't just automate it entirely else you can have people running malicious code automatically... I can do the shell scripts to create virtual users for nginx and dns. Another option is to give a normal hosting for camping users. It wouldn't be an issue to have 100-200 trusted users to have access to this e.g. we can build a camping fronted for users to apply with a selection e.g. their github account, why they want the deployment hosting etc. and then once approved we would give them a normal account that would allow them to upload files on SFTP and may be even shell (which BTW is something you don't have on heroku and other services. Of course this could be protected for security or given only to active people. How does heroku screens against abuses? Anyway if some of you would like to be alpha users in this system let me know, I will be glad to set you up as soon as I am done testing subdomains etc. ;) And of course if you have a better idea for a setup let me know. Regards David On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) wrote: WebDav for nginx: http://wiki.nginx.org/HttpDavModule Or you could implement webdav as an application nginx proxies to, just as it proxies to ruby instances. — Jenna On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson icepa...@lavabit.com (mailto:icepa...@lavabit.com) wrote: Actually setting up a reverse proxy gives better performance for the end user As you can have some sort of buffer between them
Re: dead easy deployment / Camping on the fly
I don't think we need to go as far as automatically installing gems - securing ruby is a pretty big challenge, but securing gcc? no way. — Jenna On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: Remember that we should pretty much make a Gemfile mandatory if the user makes use of gems other than Camping. For example, rack_csrf. And we should make sure that dependencies get installed. :) -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) skrev: Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software. Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well. Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets). Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere. — Jenna On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: Wonder if Google might help getting camping to run on app engine? On 1 April 2012 10:03, david costa gurugeek...@gmail.com (mailto:gurugeek...@gmail.com) wrote: Ah I forgot you can compare camping running on thin here http://run.camping.io:3301/ vs passenger at http://run.camping.io apparently db has some problems with fusion passenger (see http://run.camping.io create HTML page and test HTML page. The same code on thin works just fine... umhh oh no don't feel like more debugging ): On Sun, Apr 1, 2012 at 9:51 AM, david costa gurugeek...@gmail.com (mailto:gurugeek...@gmail.com) wrote: Okay :D after many many hours of testing I am settled for nginx and passenger. live at http://run.camping.io/ I did try every apache combination (with passenger, with cgi, etc. etc.) as is simply not really working fine. I tried some other obscure web servers too but apparently this seems to work fine for now :) other servers would run the app as CGI or FastCGI. I am not worried about speed just ease of deployment and nginx with passenger seems to do the job for now. The alternative is nginx as reverse proxy but as Jenna rightly pointed out it would spawn a lot of thin instances that might or might not be used. I did throw the sponge at Webdav on apache. It doesn't work as expected and not with all clients. It seems more suitable to store quick files than something else. Can try tomorrow with nginx but perhaps it would be nicer to have a quick camping hack to upload a file etc. but you can't just automate it entirely else you can have people running malicious code automatically... I can do the shell scripts to create virtual users for nginx and dns. Another option is to give a normal hosting for camping users. It wouldn't be an issue to have 100-200 trusted users to have access to this e.g. we can build a camping fronted for users to apply with a selection e.g. their github account, why they want the deployment hosting etc. and then once approved we would give them a normal account that would allow them to upload files on SFTP and may be even shell (which BTW is something you don't have on heroku and other services. Of course this could be protected for security or given only to active people. How does heroku screens against abuses? Anyway if some of you would like to be alpha users in this system let me know, I will be glad to set you up as soon as I am done testing subdomains etc
Re: dead easy deployment / Camping on the fly
@Isak Anything run with the `backticks operator` runs with the same privileges as the process which launched them, if using system level sandboxing, or if using some crazy sandbox built in to ruby (which probably wouldn't be very good, but maybe good enough) it'd probably just disable backticks feature. On 01/04/2012, at 9:31 PM, Isak Andersson wrote: Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: I don't think we need to go as far as automatically installing gems - securing ruby is a pretty big challenge, but securing gcc? no way. — Jenna On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: Remember that we should pretty much make a Gemfile mandatory if the user makes use of gems other than Camping. For example, rack_csrf. And we should make sure that dependencies get installed. :) -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software. Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well. Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets). Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere. — Jenna On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: Wonder if Google might help getting camping to run on app engine? On 1 April 2012 10:03, david costa gurugeek...@gmail.com wrote: Ah I forgot you can compare camping running on thin here http://run.camping.io:3301/ vs passenger at http://run.camping.io apparently db has some problems with fusion passenger (see http://run.camping.io create HTML page and test HTML page. The same code on thin works just fine... umhh oh no don't feel like more debugging ): On Sun, Apr 1, 2012 at 9:51 AM, david costa gurugeek...@gmail.com wrote: Okay :D after many many hours of testing I am settled for nginx and passenger. live at http://run.camping.io/ I did try every apache combination (with passenger, with cgi, etc. etc.) as is simply not really working fine. I tried some other obscure web servers too but apparently this seems to work fine for now :) other servers would run the app as CGI or FastCGI. I am not worried about speed just ease of deployment and nginx with passenger seems to do the job for now. The alternative is nginx as reverse proxy but as Jenna rightly pointed out it would spawn a lot of thin instances that might or might not be used. I did throw the sponge at Webdav on apache. It doesn't work as expected and not with all clients. It seems more suitable to store quick files than something else. Can try tomorrow with nginx but perhaps it would be nicer to have a quick camping hack to upload a file etc. but you can't just automate it entirely else you can have people running malicious code automatically... I can do the shell scripts to create virtual users for nginx and dns. Another option is to give a normal hosting for camping users. It wouldn't be an issue to have 100-200 trusted users to have access to this e.g. we can build a camping fronted for users to apply with a selection e.g. their github account, why they want the deployment hosting etc. and then once approved we would give
Re: dead easy deployment / Camping on the fly
Oh gods not RVM. This setup does not need another layer of complexity. On my own server, I use five thins, which run all the time, on a set of five ports which nginx proxy to. To run hundreds of camping apps, this sort of persistent setup isn't viable. CGI would work, but could be a little slow for some more complex applications. A better solution is, in my opinion, to fork. thins or unicorns could be connected with a simple camping app which forks on each request, loads a users app in to that instance, runs it once, then closes. It would be faster than CGI, not too hard to implement, and wouldn't take more resources to install more apps on the server. It also makes for a convenient place to run code before the user's application runs, which maybe useful for sandboxing or setting up web accessible logging. From what I've heard chroot isn't a good way to jail processes - it doesn't restrict network access, and it's often possible to escape the jail. Consider this: A script loads the socket library and opens port after port until computer fails. Disable the socket library? have the ruby process store a binary inside it, which it saves to a file, sets execute permission, then runs - it does the same thing. Another attack would be a fork bomb. Security is really complex. How did dot geek deal with it? did you ever have trouble with malicious users? — Jenna On Monday, 2 April 2012 at 1:49 AM, david costa wrote: Hello again ! :) well in theory we can chrot jail users but the best way is to install the gems that people need perhaps the most used ones. It will then work system wide ! The big question is who will be your typical user. If is someone you trust then you can give them even limited ssh + sftp :) Back to my ignorance: how do you folks run camping in a server ? do you use fcgi ? At work we used to run a fairly big production environment made of rails running with lighthtp and fcgi. If we were to run this as a dead simple fcgi setup did anyone set this up? I have tried all the instructions github on how to set this up with dispatcher.fcgi but failed miserably. I would can get the server installed + fcgi but how to run camping apps from there is a bit of a mystery. I am slightly frustrated because of passenger not making a simple create page/test page http://camping.sh/ working. I know is not the app as it works at http://camping.sh:3301/ Unicorn: I think you would be back to have nginx as a reverse proxy for that which can present some problems for example, default port is 3301 for camping. So you would need a script to check which port is free and run then camping --port so seems a bit complicated. Thanks David On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson icepa...@lavabit.com (mailto:icepa...@lavabit.com) wrote: Okay then. But then we'd make sure that the applications don't have privilege to install gems then. -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) skrev: @Isak Anything run with the `backticks operator` runs with the same privileges as the process which launched them, if using system level sandboxing, or if using some crazy sandbox built in to ruby (which probably wouldn't be very good, but maybe good enough) it'd probably just disable backticks feature. On 01/04/2012, at 9:31 PM, Isak Andersson wrote: Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) skrev: I don't think we need to go as far as automatically installing gems - securing ruby is a pretty big challenge, but securing gcc? no way. — Jenna On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: Remember that we should pretty much make a Gemfile mandatory if the user makes use of gems other than Camping. For example, rack_csrf. And we should make sure that dependencies get installed. :) -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) skrev: Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software
Re: dead easy deployment / Camping on the fly
@David - sorted, both those subdomains now point to your machine. :)
—
Jenna
On Saturday, 31 March 2012 at 4:10 PM, david costa wrote:
BTW if you want to point a run.camping.io (http://run.camping.io) or
host.camping.io (http://host.camping.io) or anything you like to
66.116.108.12 will then be able to show an (hopefully) working demo using the
official domain ;)
On Sat, Mar 31, 2012 at 7:08 AM, david costa gurugeek...@gmail.com
(mailto:gurugeek...@gmail.com) wrote:
oh sure ! for me is not a problem - love camping.io (http://camping.io) as
a domain !
first worry is to have a working system that is fairly stable and usable
albeit it might be launched as alpha/beta anyway :)
On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox a...@creativepony.com
(mailto:a...@creativepony.com) wrote:
We can just use a *.camping.io (http://camping.io) catchall entry
On 31/03/2012, at 3:30 PM, david costa wrote:
Hello Jenna,
we could use host.camping.io (http://host.camping.io/) or
anything.camping.io (http://anything.camping.io/) for the frontend but
if the server has to allow users to create myfancyapp.camping.io
(http://myfancyapp.camping.io/) it would be complicated as I would need
to run the camping.io (http://camping.io/) DNS on the hosting server to
create the sub domains on the fly. I started working on it more details
on a separate email.
I love your idea about the key-value database how can we implement this
?
Thanks
David
On Sat, Mar 31, 2012 at 12:21 AM, Jenna Fox a...@creativepony.com
(mailto:a...@creativepony.com) wrote:
Those both sound like brilliant servers! I'm not laughing at all. If
my mac mini is good enough for sky rim, it's good enough for web
hosting for sure!
Can we just use camping.io (http://camping.io/)?
I think starting simple is a good idea. Databases are pretty cool
among web developers for various reasons, but I think are totally
unnecessary for most smaller experimental applications. For a
beginner, I'm inclined to have key-value databases. A really simple
key-value database would work like this:
sections = key.hash.to_s(36).scan(/.{0,3}/)
sections.delete
Dir.mkdir sections[0…-1].join('/')
File.open(sections.join('/') + '-value', 'w') do |file|
file.write JSON.generate(value)
end
add in some file locking, and everything is pretty cool. It splits up
the kevin to a series of about four directories and then a file, and
conveniently fff in base36 is 19995, which is a very nice maximum
number of things you'd ever want to put in a single directory if
using something like EXT4 or HFS+. Of course, if using a B-Tree
filesystem like reiser, btrfs, zfs there is no such limitation so you
can skip the scanning joining thing and just open
database/#{key.hash} and put a value in that.
Pretty cool, no? It's really easy to turn something like that in to
what seems from the outside to be a persistent hash.
I was working on another thing called ForeverHash, which was the same
sort of idea, but used flat files. If people are interested I'd be
curious enough to revive that project with more of a CouchDB inspired
design.
I like all these filesystem based solutions (sqlite, crazy hash in
folders, flat file key-value db's) because they can be backed up and
restored via webdav or sftp or whatever, and you don't need to do any
weird stuff of configuring which ports and usernames and passwords in
your database abstraction. I prefer the idea of having a little
key-value filesystem db written in clear straight forward ruby code,
because it means kids learning can see how it works and hack at it -
as nice as sqlite is, it is in no way transparent. You at least have
to learn SQL if you want to play with it's innards, and possibly C.
On 31/03/2012, at 3:22 AM, david costa wrote:
Hello all,
I am opening a separate topic just to brainstorm the idea of a
free, simple camping deployment/hosting option.
Now this is not about re-inventing the wheel as heroku already
supports camping apps too. So this would be the ground idea:
a) This would be entirely free - no paid plans to upgrade etc.;
b) Eventually users should be able to deploy a camping application
by launching something like camping-fly myapp in the command line
and it would simply work (through a git push or similar) and make
it available live in a custom domain like camping.sh
(http://camping.sh) or ruby.am (http://ruby.am/) e.g.
myfancyapp.camping.sh (http://myfancyapp.camping.sh/) or
myfancyapp.ruby.am (http://myfancyapp.ruby.am/)
c) Database fanciness
Re: dead easy deployment / Camping on the fly
Apache? What are your thoughts on that choice I am curious? :)
—
Jenna
On Sunday, 1 April 2012 at 12:27 AM, david costa wrote:
Thank you :D as soon as the DNS will propagate it should be live.
Some updates: now added the design from camping.io (http://camping.io)
(working on the fonts) and I have narrowed down the probably easiest/best way
to do it:
using Webdav module on apache. So there will be no issue with creating real
server users and it should really be easily accessible by anyone, anywhere.
Working on some securities configurations to be sure that it works fine!
On Sat, Mar 31, 2012 at 2:52 PM, Jenna Fox a...@creativepony.com
(mailto:a...@creativepony.com) wrote:
@David - sorted, both those subdomains now point to your machine. :)
—
Jenna
On Saturday, 31 March 2012 at 4:10 PM, david costa wrote:
BTW if you want to point a run.camping.io (http://run.camping.io) or
host.camping.io (http://host.camping.io) or anything you like to
66.116.108.12 will then be able to show an (hopefully) working demo using
the official domain ;)
On Sat, Mar 31, 2012 at 7:08 AM, david costa gurugeek...@gmail.com
(mailto:gurugeek...@gmail.com) wrote:
oh sure ! for me is not a problem - love camping.io (http://camping.io)
as a domain !
first worry is to have a working system that is fairly stable and
usable albeit it might be launched as alpha/beta anyway :)
On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox a...@creativepony.com
(mailto:a...@creativepony.com) wrote:
We can just use a *.camping.io (http://camping.io) catchall entry
On 31/03/2012, at 3:30 PM, david costa wrote:
Hello Jenna,
we could use host.camping.io (http://host.camping.io/) or
anything.camping.io (http://anything.camping.io/) for the frontend
but if the server has to allow users to create
myfancyapp.camping.io (http://myfancyapp.camping.io/) it would be
complicated as I would need to run the camping.io
(http://camping.io/) DNS on the hosting server to create the sub
domains on the fly. I started working on it more details on a
separate email.
I love your idea about the key-value database how can we implement
this ?
Thanks
David
On Sat, Mar 31, 2012 at 12:21 AM, Jenna Fox a...@creativepony.com
(mailto:a...@creativepony.com) wrote:
Those both sound like brilliant servers! I'm not laughing at all.
If my mac mini is good enough for sky rim, it's good enough for
web hosting for sure!
Can we just use camping.io (http://camping.io/)?
I think starting simple is a good idea. Databases are pretty cool
among web developers for various reasons, but I think are totally
unnecessary for most smaller experimental applications. For a
beginner, I'm inclined to have key-value databases. A really
simple key-value database would work like this:
sections = key.hash.to_s(36).scan(/.{0,3}/)
sections.delete
Dir.mkdir sections[0…-1].join('/')
File.open(sections.join('/') + '-value', 'w') do |file|
file.write JSON.generate(value)
end
add in some file locking, and everything is pretty cool. It
splits up the kevin to a series of about four directories and
then a file, and conveniently fff in base36 is 19995, which is
a very nice maximum number of things you'd ever want to put in a
single directory if using something like EXT4 or HFS+. Of course,
if using a B-Tree filesystem like reiser, btrfs, zfs there is no
such limitation so you can skip the scanning joining thing and
just open database/#{key.hash} and put a value in that.
Pretty cool, no? It's really easy to turn something like that in
to what seems from the outside to be a persistent hash.
I was working on another thing called ForeverHash, which was the
same sort of idea, but used flat files. If people are interested
I'd be curious enough to revive that project with more of a
CouchDB inspired design.
I like all these filesystem based solutions (sqlite, crazy hash
in folders, flat file key-value db's) because they can be backed
up and restored via webdav or sftp or whatever, and you don't
need to do any weird stuff of configuring which ports and
usernames and passwords in your database abstraction. I prefer
the idea of having a little key-value filesystem db written in
clear straight forward ruby code, because it means kids learning
can see how it works and hack at it - as nice as sqlite is, it is
in no way transparent. You at least have to learn SQL if you want
to play with it's innards
Re: dead easy deployment / Camping on the fly
Oh whoops! I forgot to press the save button on the dns management page. Should go through now, certainly within the next hour. On fastcgi - fastcgi is not a server in itself - you cannot connect to it with a web browser. Like Passenger, it's a way for a server like nginx or apache to launch and talk to processes which return webpages directly. The easiest way to run camping apps for many different users would be regular CGI. You might think this as being terribly slow - but I assure you, if ruby and it's libraries are stored on a fast SSD disk, ruby launches incredibly quickly - further, the operating system's disk cache creates an in-ram copy of popular applications and ruby libraries, allowing the more heavily used hosted camping apps to become even more responsive. CGI certainly not worth ruling out. PHP works like this - loading and recompiling each of it's source code files for each request, unless special optimisation is done - like facebook's php to c compiler. If CGI is too slow or consumes too many resources, there's also a middle ground worth exploring - Unicorn uses a forking system, which is rather cool because it launches new ruby instances very very quickly - practically instant. It wouldn't be all that difficult to make a forking server variant which forks on each request and loads up a user's application, runs it, then closes (or maybe idles out after five minutes). There are all sorts of interesting ways we could optimise existing server ideas to work very well with small infrequently used applications on different domains for different fully isolated users, rather like the ways PHP tends to be hosted which make it so practical for large numbers of users running infrequently accessed applications. Sandboxing is also something worth investigating. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: dead easy deployment / Camping on the fly
The main downside to passenger, is that when things go wrong, it can be a bit 'thar be monsters in here!' It's a bit of a mysterious technology which isn't very well documented when stuff doesn't work, or at least it wasn't when I was playing with it about 8 months ago. I ended up settling on thins to get away from passenger, though for a while I was using passenger on my local mac apache instance for testing. — Jenna On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson icepa...@lavabit.com (mailto:icepa...@lavabit.com) wrote: Actually setting up a reverse proxy gives better performance for the end user As you can have some sort of buffer between them. The Unicorn server takes care of whatever nginx asks for, and while it waits it can server whatever unicorn outputs. It doesn't have to wait for what it outputs itself to get done because you have a queue. Or something like that. Mh I am not really sure it would be a better performance as it would be anyway more than one process. I think that phusion passenger is pretty much the most robust solution for this. Some people actually out Apache to do PHP stuff while nginx acts as a reverse proxy and actually shows things to the user in the same way you'd do with Unicorn/Thin Well this would be even more load as two web servers will run at the same time. Apache + Phusion passenger already lets you run .php or anything you want. But this is not the issue really. I think this is all fine in term of mono user. Question: if you have 100 users how do you configure it ? How can you add webdav support on the top of the Nginx + unicorn setup ? But perhaps That's too much for a server ment to serve other peoples applications! Then you have to scale down the resources used. I am open to anything but if I can't do something I might ask for some brave volunteers to set it up as I really never tried anything else beside for local/quick test deployment. ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: dead easy deployment / Camping on the fly
WebDav for nginx: http://wiki.nginx.org/HttpDavModule Or you could implement webdav as an application nginx proxies to, just as it proxies to ruby instances. — Jenna On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson icepa...@lavabit.com (mailto:icepa...@lavabit.com) wrote: Actually setting up a reverse proxy gives better performance for the end user As you can have some sort of buffer between them. The Unicorn server takes care of whatever nginx asks for, and while it waits it can server whatever unicorn outputs. It doesn't have to wait for what it outputs itself to get done because you have a queue. Or something like that. Mh I am not really sure it would be a better performance as it would be anyway more than one process. I think that phusion passenger is pretty much the most robust solution for this. Some people actually out Apache to do PHP stuff while nginx acts as a reverse proxy and actually shows things to the user in the same way you'd do with Unicorn/Thin Well this would be even more load as two web servers will run at the same time. Apache + Phusion passenger already lets you run .php or anything you want. But this is not the issue really. I think this is all fine in term of mono user. Question: if you have 100 users how do you configure it ? How can you add webdav support on the top of the Nginx + unicorn setup ? But perhaps That's too much for a server ment to serve other peoples applications! Then you have to scale down the resources used. I am open to anything but if I can't do something I might ask for some brave volunteers to set it up as I really never tried anything else beside for local/quick test deployment. ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: camping paid examples + screencasts ?
Seconding Vimeo - it's exactly the sort of creative friendly helpful community we get along so great with. :) I wouldn't bother with youtube. The main thing is that people can comment and embed and vote/like it and all that wonderful stuff. :) — Jenna On Friday, 30 March 2012 at 5:28 PM, Isak Andersson wrote: I'd like to see the screencasts on YouTube or Vimeo where everyone can view them. That's fine, I can post them to my YouTube channel too. David didn't really give a restriction on what I could do with the Videos. :) DaveE Cheers! - Isak Andersson ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: camping paid examples + screencasts ?
Sounds great - my sites are the same setup, but with regular thin. :) — Jenna On Friday, 30 March 2012 at 5:47 PM, Isak Andersson wrote: Well, why not just go with both? Bigger audience! The more places the better. Vimeo is a bit better though. Anyways, about the deployment video. I was thinking I hook an application up with Unicorn and putting nginx on top of it. How does that sound? - Isak Andersson On 03/30/2012 08:35 AM, Jenna Fox wrote: Seconding Vimeo - it's exactly the sort of creative friendly helpful community we get along so great with. :) I wouldn't bother with youtube. The main thing is that people can comment and embed and vote/like it and all that wonderful stuff. :) — Jenna On Friday, 30 March 2012 at 5:28 PM, Isak Andersson wrote: I'd like to see the screencasts on YouTube or Vimeo where everyone can view them. That's fine, I can post them to my YouTube channel too. David didn't really give a restriction on what I could do with the Videos. :) DaveE Cheers! - Isak Andersson ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list Die neusten PC-Treiber runterladen Aktualisiert im Nu alle PC-Treiber! http://click.lavabit.com/4xr69tw397kinowkztda5dhjqsfhxppib9muja6rbtypp3jqtksb/ ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: camping paid examples + screencasts ?
Quickly while we're on the topic of typefaces: Our web design makes use of a typeface called Topstitch in the sidebar navigational menu. The type designer Typodermic donated a license to use this typeface on our site, but it is a commercial font so should not be used outside of official camping related projects. Comic Zine is a free-as-in-cost typeface, and I have special permission from the type designer for our 'fill' variant used on our site. The fill variant is not an official variant of the typeface and shouldn't be distributed as a free typeface for other projects and some care should be given to not give the impression that our varient is in any way endorsed by the original type designer. Seeing as the screencasts are going to be a part of the camping website, there's no issue using any of these typefaces in related web designs. :) For the sake of consistency, where possible try to use the same html and css codes as the main site if it's not too much effort, so we may apply new styles all in one place. — Jenna On Friday, 30 March 2012 at 11:43 PM, david costa wrote: This is good but let's use the same font as the website :) http://www.fontsquirrel.com/fonts/Comic-Zine-OT On Fri, Mar 30, 2012 at 9:48 AM, Isak Andersson icepa...@lavabit.com (mailto:icepa...@lavabit.com) wrote: I've heard nothing but good myself. The biggest difference is that Slim is a bit more friendly isn't it? And what did you think about the image :) - Isak -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) skrev: I've certainly heard nothing bad of Unicorn from my friend who works in the github server management team. — Jenna On Friday, 30 March 2012 at 6:12 PM, Isak Andersson wrote: Yeah, it's just a matter of preference I guess. I like both but I'm going with Unicorn :) Also, I guess I should ask the whole mailing list on this, I created a little base thing for presentations when I'm just talking concepts in the screencasts. I took some assets from the Camping.io (http://Camping.io) site to make it feel familiar. The thing I'm wondering about is the title font. I went with a goofy one just because Camping is damn fun, but I'm not sure if I find it perfect.. What do you guys think? Here's the image: http://i.imgur.com/8zLJc.png On 03/30/2012 08:58 AM, Jenna Fox wrote: Sounds great - my sites are the same setup, but with regular thin. :) — Jenna On Friday, 30 March 2012 at 5:47 PM, Isak Andersson wrote: Well, why not just go with both? Bigger audience! The more places the better. Vimeo is a bit better though. Anyways, about the deployment video. I was thinking I hook an application up with Unicorn and putting nginx on top of it. How does that sound? - Isak Andersson On 03/30/2012 08:35 AM, Jenna Fox wrote: Seconding Vimeo - it's exactly the sort of creative friendly helpful community we get along so great with. :) I wouldn't bother with youtube. The main thing is that people can comment and embed and vote/like it and all that wonderful stuff. :) — Jenna On Friday, 30 March 2012 at 5:28 PM, Isak Andersson wrote: I'd like to see the screencasts on YouTube or Vimeo where everyone can view them. That's fine, I can post them to my YouTube channel too. David didn't really give a restriction on what I could do with the Videos. :) DaveE Cheers! - Isak Andersson ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list Die neusten PC-Treiber runterladen Aktualisiert im Nu alle PC-Treiber! http://click.lavabit.com/4xr69tw397kinowkztda5dhjqsfhxppib9muja6rbtypp3jqtksb/ ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list Get the best selection of equity home loans sites here. Click
Re: camping paid examples + screencasts ?
I've never heard of that. Camping is a rack app. It works with any kind of rack server. Thin is in no way official or standard. Use whatever you think is good! There are so many ways to deploy ruby apps and nearly all of them are really great. It's not worth fussing too much over unless you're making a huge scale web app with a zillionty users. I personally use the web technology which has the most minimalist zen-style websites. I know some people like horses and unicorns and rainbows and stuff and that's cool too! Nobody likes webrick. Don't use webrick. — Jenna On Saturday, 31 March 2012 at 12:41 AM, Isak Andersson wrote: Oh, thin is a standard in Camping? Never noticed. -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. david costa gurugeek...@gmail.com (mailto:gurugeek...@gmail.com) skrev: For the deployment video I think you should perhaps start with the standard configuration which has thin and nginx but of course if you have time you can do one with Unicorn too. The idea is to make it easy for users to run without having to install too much extra stuff. Best Regards David On Fri, Mar 30, 2012 at 8:47 AM, Isak Andersson icepa...@lavabit.com (mailto:icepa...@lavabit.com) wrote: Well, why not just go with both? Bigger audience! The more places the better. Vimeo is a bit better though. Anyways, about the deployment video. I was thinking I hook an application up with Unicorn and putting nginx on top of it. How does that sound? - Isak Andersson On 03/30/2012 08:35 AM, Jenna Fox wrote: Seconding Vimeo - it's exactly the sort of creative friendly helpful community we get along so great with. :) I wouldn't bother with youtube. The main thing is that people can comment and embed and vote/like it and all that wonderful stuff. :) — Jenna On Friday, 30 March 2012 at 5:28 PM, Isak Andersson wrote: I'd like to see the screencasts on YouTube or Vimeo where everyone can view them. That's fine, I can post them to my YouTube channel too. David didn't really give a restriction on what I could do with the Videos. :) DaveE Cheers! - Isak Andersson ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list Die neusten PC-Treiber runterladen Aktualisiert im Nu alle PC-Treiber! http://click.lavabit.com/4xr69tw397kinowkztda5dhjqsfhxppib9muja6rbtypp3jqtksb/ ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list Trabaja desde tu casa 100% GRATIS Las mejores encuestas para ti http://click.lavabit.com/rxuk6ujuhcqbm98z4bn1kshgdohpjoo9wzuabkf7sfsc5qrtd7oy/ ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: camping paid examples + screencasts ?
For screencasts I recommend whichever of the fashionable web servers has the coolest looking logo when zoomed out a bit, as it'll look good on video. Unicorn has a pretty great logo which scales well. Who ever said ruby severs don't scale? — Jenna On Saturday, 31 March 2012 at 12:55 AM, Jenna Fox wrote: I've never heard of that. Camping is a rack app. It works with any kind of rack server. Thin is in no way official or standard. Use whatever you think is good! There are so many ways to deploy ruby apps and nearly all of them are really great. It's not worth fussing too much over unless you're making a huge scale web app with a zillionty users. I personally use the web technology which has the most minimalist zen-style websites. I know some people like horses and unicorns and rainbows and stuff and that's cool too! Nobody likes webrick. Don't use webrick. — Jenna On Saturday, 31 March 2012 at 12:41 AM, Isak Andersson wrote: Oh, thin is a standard in Camping? Never noticed. -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. david costa gurugeek...@gmail.com (mailto:gurugeek...@gmail.com) skrev: For the deployment video I think you should perhaps start with the standard configuration which has thin and nginx but of course if you have time you can do one with Unicorn too. The idea is to make it easy for users to run without having to install too much extra stuff. Best Regards David On Fri, Mar 30, 2012 at 8:47 AM, Isak Andersson icepa...@lavabit.com (mailto:icepa...@lavabit.com) wrote: Well, why not just go with both? Bigger audience! The more places the better. Vimeo is a bit better though. Anyways, about the deployment video. I was thinking I hook an application up with Unicorn and putting nginx on top of it. How does that sound? - Isak Andersson On 03/30/2012 08:35 AM, Jenna Fox wrote: Seconding Vimeo - it's exactly the sort of creative friendly helpful community we get along so great with. :) I wouldn't bother with youtube. The main thing is that people can comment and embed and vote/like it and all that wonderful stuff. :) — Jenna On Friday, 30 March 2012 at 5:28 PM, Isak Andersson wrote: I'd like to see the screencasts on YouTube or Vimeo where everyone can view them. That's fine, I can post them to my YouTube channel too. David didn't really give a restriction on what I could do with the Videos. :) DaveE Cheers! - Isak Andersson ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list Die neusten PC-Treiber runterladen Aktualisiert im Nu alle PC-Treiber! http://click.lavabit.com/4xr69tw397kinowkztda5dhjqsfhxppib9muja6rbtypp3jqtksb/ ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list Trabaja desde tu casa 100% GRATIS Las mejores encuestas para ti http://click.lavabit.com/rxuk6ujuhcqbm98z4bn1kshgdohpjoo9wzuabkf7sfsc5qrtd7oy/ ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: camping paid examples + screencasts ?
They're all really really fast. I like the idea of how unicorn works though - it sounds quite nice. Apache for legacy stuff only these days. I wonder if there are any server's with a logo as awesome as LLVM's. — Jenna On Saturday, 31 March 2012 at 1:06 AM, Isak Andersson wrote: That's what I was suspecting. I'll go with unicorn then. Apparently it handles more requests/sec than Thin. But that might be old benchmarks who knows. Not that speed is everything. Stability etc is also important. But whatever. There shouldn't be too much of a difference in setting them up anyways so anyone who decides to you Thin or Mongrel will probably not have big of an issue setting that up. I guess the bigger difference would be hooking one of the Rack servers to Apache instead of Nginx. But I think Nginx is a better option since it's ment to serve static pages and Unicorn will be the one handling all the dynamic stuff. -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) skrev: For screencasts I recommend whichever of the fashionable web servers has the coolest looking logo when zoomed out a bit, as it'll look good on video. Unicorn has a pretty great logo which scales well. Who ever said ruby severs don't scale? — Jenna On Saturday, 31 March 2012 at 12:55 AM, Jenna Fox wrote: I've never heard of that. Camping is a rack app. It works with any kind of rack server. Thin is in no way official or standard. Use whatever you think is good! There are so many ways to deploy ruby apps and nearly all of them are really great. It's not worth fussing too much over unless you're making a huge scale web app with a zillionty users. I personally use the web technology which has the most minimalist zen-style websites. I know some people like horses and unicorns and rainbows and stuff and that's cool too! Nobody likes webrick. Don't use webrick. — Jenna On Saturday, 31 March 2012 at 12:41 AM, Isak Andersson wrote: Oh, thin is a standard in Camping? Never noticed. -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. david costa gurugeek...@gmail.com (mailto:gurugeek...@gmail.com) skrev: For the deployment video I think you should perhaps start with the standard configuration which has thin and nginx but of course if you have time you can do one with Unicorn too. The idea is to make it easy for users to run without having to install too much extra stuff. Best Regards David On Fri, Mar 30, 2012 at 8:47 AM, Isak Andersson icepa...@lavabit.com (mailto:icepa...@lavabit.com) wrote: Well, why not just go with both? Bigger audience! The more places the better. Vimeo is a bit better though. Anyways, about the deployment video. I was thinking I hook an application up with Unicorn and putting nginx on top of it. How does that sound? - Isak Andersson On 03/30/2012 08:35 AM, Jenna Fox wrote: Seconding Vimeo - it's exactly the sort of creative friendly helpful community we get along so great with. :) I wouldn't bother with youtube. The main thing is that people can comment and embed and vote/like it and all that wonderful stuff. :) — Jenna On Friday, 30 March 2012 at 5:28 PM, Isak Andersson wrote: I'd like to see the screencasts on YouTube or Vimeo where everyone can view them. That's fine, I can post them to my YouTube channel too. David didn't really give a restriction on what I could do with the Videos. :) DaveE Cheers! - Isak Andersson ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list Die neusten PC-Treiber runterladen Aktualisiert im Nu alle PC-Treiber! http://click.lavabit.com/4xr69tw397kinowkztda5dhjqsfhxppib9muja6rbtypp3jqtksb/ ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list Trabaja desde
Re: camping paid examples + screencasts ?
Disable comments on youtube perhaps? P.S. RE: 'unicorn sounds nice' for those who haven't heard it yet, this is what Unicorn sounds like: http://d.pr/olau — Jenna On Saturday, 31 March 2012 at 1:20 AM, Dave Everitt wrote: On 30 Mar 2012, at 14:51, david costa wrote: Vimeo is great (I use it for a lot of professional videos) but perhaps we should have them on youtube too because google ranks video from youtube higher on their searches. YouTube: loads of trolls (-2) but lots of eyeballs (+1) = total: -1 Vimeo: a much nicer place (+1), fewer eyeballs (-1) = total: 0 Both is fine, but if YouTube, perhaps at least a YouTube Camping channel? DaveE ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: camping paid examples + screencasts ?
Dropbox sounds like a great idea, except for if it starts syncing an sqlite db constantly. Another good option would be if we can make an nginx config (or a camping app!) which does WebDAV - finder, explorer, and nautilus all support it, and it means site upload bits and site serving bits both come from one program on the server, simplifying setup. — Jenna Fox On Saturday, 31 March 2012 at 5:28 AM, Dave Everitt wrote: Having just spent a whole afternoon: updating my sources in Debian just to install curl just to install rvm and check rvm requirements... [paused here and logged out of server] to find that I now have to add my user to the rvm group (to find useradd -G rvm myusername *fails*)... then install a pile of Ruby dependencies that aptitude can't even find... I'm all for this! I'd argue PHP became a default for web designers-turned-developers partly because of the no-brainer beginner installation (dump all the php files in your root dir!). So much is taken for granted and glossed over in both the Ruby and Python communities about server setups, and there's so much outdated and conflicting information out there, that a quick route (a la Heroku but more selective and even easier) would be welcome. For a real no-brainer I'm even thinking Dropbox (which can run per- user on a server) and/or git and/or a script that deploys once the user is set both up on the server and locally, like cap deploy but really stripped down. DaveE On 30 Mar 2012, at 17:09, david costa wrote: I agree with Dave that we have to go pretty much back to basic when is about deployment. I have been running a free hosting for several years (2001 to 2006 I think http://dotgeek.org) and I think that many programmers get lost in running thins in reverse proxy which, as far as I gather, is getting the main web server (Nginx) to act as a proxy to your app more at http://blog.sosedoff.com/2009/07/04/how-to-deploy-sinatra-merb-applications-with-nginx/ From years in PHP this is already a big change :) Wondering if we could set up a free hosting for camping that is dead easy like on command line camping-remote myapp and make it run on the fly without having to configure anything and/or something where you simply drop your nuts.rb in the folder you want in apache/anything and it runs automagically or in a very simple way. But I am also very happy with how it works now :) just thinking loud! David On Fri, Mar 30, 2012 at 4:59 PM, Dave Everitt dever...@innotts.co.uk wrote: I'll go with unicorn then. Apparently it handles more requests/sec than Thin. But that might be old benchmarks who knows. Sounds great - my sites are the same setup, but with regular thin. :) All I ask is that it avoids sentences such as this one (from Unicorn): Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between Unicorn and slow clients. Embarrassing to admit it and I'm going to look like a dumbo here, but I don't really know what a reverse proxy is. I hate messing with my servers (ancient Ubuntu and not-so-ancient Debian, running Apache) any more than absolutely necessary. So I wouldn't understand how to apply the information in that sentence, or - more crucially - whether I can ignore it for a site(s) with small-to- modest traffic. The Thin site does a nice, minimal job of explaining how to get things running, but I'll be the first in line to watch the deployment screencast and get Unicorn installed. After trying to teach this stuff to complete beginners and failing, what I'm saying is: don't take any server-related knowledge for granted when explaining deployment - this is where a lot of frameworks fall down - I spent *days* trying to get one server configured just to run something simple (okay, that was Django and mod_wsgi - sshhh - but the same kinds of hoops still need jumping through). I guess the bigger difference would be hooking one of the Rack servers to Apache instead of Nginx. But I think Nginx is a better option since it's ment to serve static pages and Unicorn will be the one handling all the dynamic stuff. ...but please include an Apache-only setup for those of us who haven't installed Nginx (and really should, but just... haven't) and have very modest loads, and a stack of legacy sites to run. the simple dumbest build will launch the webserver with thin (camping --port 80) Nice'n'simple, but (if starting out and watching a screencast) I'd want to a mention of what dependencies need installing on my server to even get that far... I'm
Re: camping paid examples + screencasts ?
We have a tumblr blog - maybe we should turn on the 'ask' feature and make it a Q and A thing. It would grow in to a google friendly fact book, a bit like a stack exchange, for looking up specific problems and techniques. Tumblr is a nice medium for adding photos and screencasts and the likes too. — Jenna Fox On Thursday, 29 March 2012 at 12:22 AM, Paul van Tilburg wrote: On Wed, Mar 28, 2012 at 06:57:51AM -0600, Philippe Monnet wrote: I think it would be fun too. Love meta stuff. In general I think the more tutorials / screencasts / posts / sites on Camping, the merrier. Although I generally agree, I'd prefer them to be somewhat organised/structured. For example, the blog is a good basic app, but I would like to have tutorials for specific things such as: adding cookies, sessions, using different view/template systems, integrating multiple apps, etc. Rather than having a screencast of a wiki app that happens to mention sessions. In my opinion the Camping site should answer questions/help out with different aspects of creating/extending/maintaining a Camping application. This is something that currently requires joining #camping on IRC, asking the question and waiting for a long time. (Not there that is anything whatsover wrong with our IRC-channel. :) Cheers, Paul ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- Web: http://paul.luon.net/home/ | E-mail: p...@luon.net Jabber/GTalk: p...@luon.net | GnuPG key ID: 0x50064181 ___ 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: camping paid examples + screencasts ?
I just don't see the point in creating our own elaborate infrastructure which we then have to maintain indefinitely, which is more complicated than static files. Our site is static html right now because there's nothing about the site which is dynamic - but those static files were rendered by a camping app which I just mirrored to static files recently using wget so we could switch things over to github pages. Unless there's going to be some dynamic element to the camping site, I'd rather the stability and scalability afforded to us by github pages and static files than some token ritual of dogfooding. Both the sites of Ruby on Rails and Sinatra seem to use caching servers between their users and ruby backends, with sinatra's in particular caching responses for many hours. I think we're winning the ruby race - our cache caches for days, even weeks! It's a really smart cache. As for forums, I'm interested, and I agree it would be best done as a camping app, if for no better reason that there isn't really any good free forum software still being maintained which runs on ruby, as far as I know. For our blog though, tumblr is great. It's had very little downtime in recent weeks. I think it's worth forgiving them - their user base became something like ten times as big in the space of one day, after their collaboration with the The Colbert Report - for a site which takes photo, music, and video uploads, that's a pretty substantial change. They seem to have sorted it out now, only having very minor blips from time to time. Further, tumblr is based on the tumblog concept, which was pioneered and named by none other than our former friend Why The Lucky Stiff, and itself does run on our close relative, Ruby On Rails. In fact, a large proportion of GitHub is a Rails app too. — Jenna On Thursday, 29 March 2012 at 6:29 AM, david costa wrote: Hi Jenna this is great ! let's see how the screencasts come along then you can see. Just one point about tumblr (which is good don't get me wrong) wouldn't it be better to have a small site on camping ? I am pretty excited to build this in camping and show the screencasts inside it. Of course will need to show code not nice words only ;) but this should be the final aim. I am not asking anyone to do it/code it etc. I am just saying this should be the ultimate goal because with no camping code in production people might think this is just a quick hack just for the fun of it with not much of a real use beside a proof of concept... which is a bit of a pity. Like there are hundreds of frameworks on git, google code etc. but how many can be bothered to try them out without having some working samples or a good site (and I really like your design !!) to show how is this working ? For example there is some activity in the mailing list so it could be something nice to show on the website (like this topic at http://comments.gmane.org/gmane.comp.lang.ruby.camping.general/1648) but of course within the site and not an external link. This could be enough while there is no forum etc. On another note tumblr is not exactly very stable ! *this said* I totally see your point as you have this functionality already on tumblr so if one wants to be up and quickly with something it is certainly better than any bigger but uncoded masterplan :) Regards David On Wed, Mar 28, 2012 at 3:52 PM, Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) wrote: We have a tumblr blog - maybe we should turn on the 'ask' feature and make it a Q and A thing. It would grow in to a google friendly fact book, a bit like a stack exchange, for looking up specific problems and techniques. Tumblr is a nice medium for adding photos and screencasts and the likes too. — Jenna Fox On Thursday, 29 March 2012 at 12:22 AM, Paul van Tilburg wrote: On Wed, Mar 28, 2012 at 06:57:51AM -0600, Philippe Monnet wrote: I think it would be fun too. Love meta stuff. In general I think the more tutorials / screencasts / posts / sites on Camping, the merrier. Although I generally agree, I'd prefer them to be somewhat organised/structured. For example, the blog is a good basic app, but I would like to have tutorials for specific things such as: adding cookies, sessions, using different view/template systems, integrating multiple apps, etc. Rather than having a screencast of a wiki app that happens to mention sessions. In my opinion the Camping site should answer questions/help out with different aspects of creating/extending/maintaining a Camping application. This is something that currently requires joining #camping on IRC, asking the question and waiting for a long time. (Not there that is anything whatsover wrong with our IRC-channel. :) Cheers, Paul
Re: camping paid examples + screencasts ?
David, that's not at all what I meant. We don't have any dynamic content right now, so there is no point running it as if it were a dynamic site right now. That could be changed in a matter of hours if we did add something dynamic, like a forum. I'm not sure how a screencast would relate to a dynamic website, and I was certainly not suggesting a tumblr log would be the most ideal way to showcase screencasts - just that it is compatible with all sorts of media as a way of responding to questions with visual as well as textual answers. I'm more than happy for anyone to implement grand ideas for the camping website. Github Pages is just what we're using at the moment because static pages has been everything we need recently. I'd love to see camping have a great site. If you'd like to make one, go ahead! You have complete freedom - feel free to use any of the assets of our current website (it's up at https://github.com/camping/camping.io/tree/gh-pages ) - There really is no thought leader of camping to convince of anything. If you want to do something, lets do it! No matter how cooky or unusual. One of the things I wanted to do for a while was create a free camping web host, ala dotgeek, with a very simple file-based key-value database and the option of sqlite. Unfortunately time has gotten the better of me for that project, but I still think it'd be totally awesome to do! Sandboxing and security issues I'm not too sure about, which is one of the setbacks for that project. Judofyr's been working on a tool for assembling a better camping book, but I'm not sure if he's still working on that. — Jenna On Thursday, 29 March 2012 at 10:36 AM, david costa wrote: Hello, I am a bit at a loss :) Really I don't see how we can promote a camping with screencast and examples e.g. even a blog example when we are then essentially saying that it would be pointless anyway for camping to code a blog as there is tumblr (or you name it, wordpress, blogger etc.). Isn't the point of coding/camping to experiment, let the imagination run wild while building something cool (not just a blog of course) ? I don't think that a totally static website is necessarily a good thing. It is very limiting and creates a single way to dialogue with existing/future users which can be done in a number of ways even without the forum (e.g. fetching displaying the mailing list, allow comments on certain topics, QA etc.). Sure you can do that with tumblr and pretty well but in my humble opinion that's not the best way to promote the framework. But hey what do I know ? I just finished reading Running Sinatra and they do the very same thing in their sample blog (last chapter). They tell you how to create a sinatra app where you do not have an online editor and all it does it to create static HTML files. I thought WOW why would I go and install, learn the sinatra way if this is the display of what I can do with it ? Nothing wrong with static html. I have a blog with static files too (but hey at least I have disqus comments embedded on each files so there is a way to communicate with users + rsync and other stuff ) and you know..it is 15 lines of bash code. It does exactly the same of that Sinatra app from the book without having to run or install anything. So I really don't get it I think ! Will see how I can progress with the screencasts but making them to display them on a tumblr blog is not exactly very motivating. Perhaps I got caught by the enthusiasm too quickly - my bad! Best Wishes David On Thu, Mar 29, 2012 at 12:55 AM, Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) wrote: I just don't see the point in creating our own elaborate infrastructure which we then have to maintain indefinitely, which is more complicated than static files. Our site is static html right now because there's nothing about the site which is dynamic - but those static files were rendered by a camping app which I just mirrored to static files recently using wget so we could switch things over to github pages. Unless there's going to be some dynamic element to the camping site, I'd rather the stability and scalability afforded to us by github pages and static files than some token ritual of dogfooding. Both the sites of Ruby on Rails and Sinatra seem to use caching servers between their users and ruby backends, with sinatra's in particular caching responses for many hours. I think we're winning the ruby race - our cache caches for days, even weeks! It's a really smart cache. As for forums, I'm interested, and I agree it would be best done as a camping app, if for no better reason that there isn't really any good free forum software still being maintained which runs on ruby, as far as I know. For our blog though, tumblr is great. It's had very little downtime in recent weeks. I think it's
Re: camping paid examples + screencasts ?
Sounds great. Let me know if you need any camping.io subdomains for your projects. That goes for all of you! — Jenna On Thursday, 29 March 2012 at 11:54 AM, david costa wrote: Hello Jenna, apologizes for the misunderstanding ! must be the late hour here in Zurich :) I am 100% in agreement with the idea: if someone is not happy about something should just roll his/her sleeves and code it/provide it to the project. Didn't meant to criticize your current camping setup. You and Magnus did a great job. I like your design (even if some people don't) as to me a design has to be unique and original and yours really is. My only fear was - am I doing something that people might want or is really useless ? This is also why I emailed you off list before starting the screencasting idea :) You probably have some mind reading skills ;) as I was really thinking about the camping FREE hosting (with less limitations than heroku and perhaps easier or with more DBs options) Unfortunately my sysadmin is currently under a lot of work as we are moving several severs to SSD drivers (a similar setup would be really cool for DB powered camping applications as MySQL 5.6 on SSD is just amazingly fast) but eventually he might find the time to do it in a not too distant future. So bottom line: will go ahead with the 6-7 screencasts (Isak is doing it) and we take it from there. Absolutely fine to show them (if you and the community like them) on tumblr or even in a static page. It doesn't really matter in the end ! IF in parallel I manage to do something decent in camping while the screencasts are done will host it myself as a proof of concepts and see how it is. Of course everyone can contribute. I would say a good way to gather many examples by the community (existing or future users) could be this: after the screencasts we can try to run a camping coding marathon - competition. We can have 3 prizes and we can let people (or a jury) vote for the most original idea / usage. Prizes could be something like a tablet and/or other IT gears. With a bit of advertising it could be successful. I do welcome any comment on this. Thanks again and sorry for the misunderstanding Best Regards David On Thu, Mar 29, 2012 at 1:54 AM, Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) wrote: David, that's not at all what I meant. We don't have any dynamic content right now, so there is no point running it as if it were a dynamic site right now. That could be changed in a matter of hours if we did add something dynamic, like a forum. I'm not sure how a screencast would relate to a dynamic website, and I was certainly not suggesting a tumblr log would be the most ideal way to showcase screencasts - just that it is compatible with all sorts of media as a way of responding to questions with visual as well as textual answers. I'm more than happy for anyone to implement grand ideas for the camping website. Github Pages is just what we're using at the moment because static pages has been everything we need recently. I'd love to see camping have a great site. If you'd like to make one, go ahead! You have complete freedom - feel free to use any of the assets of our current website (it's up at https://github.com/camping/camping.io/tree/gh-pages ) - There really is no thought leader of camping to convince of anything. If you want to do something, lets do it! No matter how cooky or unusual. One of the things I wanted to do for a while was create a free camping web host, ala dotgeek, with a very simple file-based key-value database and the option of sqlite. Unfortunately time has gotten the better of me for that project, but I still think it'd be totally awesome to do! Sandboxing and security issues I'm not too sure about, which is one of the setbacks for that project. Judofyr's been working on a tool for assembling a better camping book, but I'm not sure if he's still working on that. — Jenna On Thursday, 29 March 2012 at 10:36 AM, david costa wrote: Hello, I am a bit at a loss :) Really I don't see how we can promote a camping with screencast and examples e.g. even a blog example when we are then essentially saying that it would be pointless anyway for camping to code a blog as there is tumblr (or you name it, wordpress, blogger etc.). Isn't the point of coding/camping to experiment, let the imagination run wild while building something cool (not just a blog of course) ? I don't think that a totally static website is necessarily a good thing. It is very limiting and creates a single way to dialogue with existing/future users which can be done in a number of ways even without the forum (e.g. fetching displaying the mailing list, allow comments on certain topics, QA etc.). Sure you can
Re: camping paid examples + screencasts ?
I'd be more than happy to help with screencasts and writing. I'm quite good with Final Cut and Motion, but someone else would need to take the lead on that and delegate tasks to me, as my mind is tied up in other projects for the next few months. — Jenna On Tuesday, 27 March 2012 at 8:59 AM, Dave Everitt wrote: another thread has just come alive about showing the alive-ness of Camping (Re: +1 shorter domain name), so you might want to take a look there too. It's a generous offer and I'm sure someone(s) will take it up. I actually enjoy doing tutorial stuff like this, but we're a diverse bunch with many different approaches, so I'd be unhappy about putting any kind of identity on it, and I'd want to work with at least one other Camping community person (partly because my Camping knowledge - and general approach - is that of the eternal newbie/generalist) - Dave E. Wow I think I didn't really manage to be understood (but I did write I would be willing to sponsor so I thought it was). :) I am willing to pay / sponsor the creation of camping examples and screencasts :) So if anyone is interested let me kno ! ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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
+1 shorter domain name
Just thought it worth mentioning, we now collectively do own camping.io - this is where judofyr's site will go when it's ready, and we're planning to use github pages as hosting for now (yes, we won't be running it as a dynamic camping website, seeing as we can't think of any good dynamic functionality) Speaking of dynamic functionality. Do you guys remember the old ruby/rails beast forums? They kind of died out, but a really simple clean forum can be a really nice thing, and it send a clear message by being publicly readable - camping is not dead. You wouldn't need to join a mailing list to find that out. I've been thinking about forums a lot lately, and I think http://camendesign.com/nononsense_forum is a really great way to build a really simple forum - you use folders for sub forums, and rss or atom feeds for threads. This way you can subscribe to them also, and it has a built in API of sorts. Probably atom is the way to go. rss is a bit of a hack job. I'm really keen to kill this myth that camping is inactive. Another way I think we might do this is to bring in camping-related projects as well. In the same way rails is the home of active record, perhaps camping aught to be the home of things like mab. — Jenna Fox ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: +1 shorter domain name
That sounds great, but I remain skeptical that people will spend the time necessary to write good quality articles (or anything at all) on a wiki, seeing as we have had a wiki as our entire website for quite a long time. Do you have any thoughts on who would contribute and what their motivations would be? — Jenna Fox On Wednesday, 1 February 2012 at 2:18 PM, adam moore wrote: I've recently been using Arch linux and 90% of the appeal comes from their awesome user-led wiki.. Something which we can gradually add to, build on camping of course, and which hand-holds beginners would be ideal I think On Wed, Feb 1, 2012 at 5:55 AM, Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) wrote: Just thought it worth mentioning, we now collectively do own camping.io (http://camping.io) - this is where judofyr's site will go when it's ready, and we're planning to use github pages as hosting for now (yes, we won't be running it as a dynamic camping website, seeing as we can't think of any good dynamic functionality) Speaking of dynamic functionality. Do you guys remember the old ruby/rails beast forums? They kind of died out, but a really simple clean forum can be a really nice thing, and it send a clear message by being publicly readable - camping is not dead. You wouldn't need to join a mailing list to find that out. I've been thinking about forums a lot lately, and I think http://camendesign.com/nononsense_forum is a really great way to build a really simple forum - you use folders for sub forums, and rss or atom feeds for threads. This way you can subscribe to them also, and it has a built in API of sorts. Probably atom is the way to go. rss is a bit of a hack job. I'm really keen to kill this myth that camping is inactive. Another way I think we might do this is to bring in camping-related projects as well. In the same way rails is the home of active record, perhaps camping aught to be the home of things like mab. — Jenna Fox ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Camping 2.2 pre-release
failing test case, running in camping:
def layout
text !DOCTYPE html\n
html { head { title foo } }
end
Markaby output:
!DOCTYPE html
htmlheadtitlefoo/title/head/html
Mab output:
lt;!DOCTYPE htmlgt;
htmlheadtitlefoo/title/head/html
—
Jenna Fox
On Wednesday, 25 January 2012 at 10:00 PM, Magnus Holm wrote:
gem install camping --source http://gems.judofyr.net/
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Re: Mab is pretty much done
Excellent work! and some great examples you have in that readme ;) — Jenna Fox On Monday, 16 January 2012 at 6:26 AM, Magnus Holm wrote: Just thought I'd let you know that I've been working on Mab lately: https://github.com/camping/mab. This will replace Markaby in the next release. Also, I've been benchmarking it on this simple, but view-heavy, app. Camping w/Markaby: 480 requests/second Camping w/Mab: 1490 requests/second Camping.goes :App module App::Controllers class Index def get render :index end end end module App::Views def index div.page.index do div.big do h1.main! Welcome! World. end end end def layout html do head do title Web Page end body do div.wrapper! do yield end end end end end // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Is it possible to read session data from Camping::Session in a middleware?
If you look in to the Rack docs, you'll find more info on how to chain middleware together. Camping provides some friendly shortcuts to that, but 'including a module' is not how that's supposed to work, is my understanding. Essentially Rack middleware work by creating an object which responds to a 'call' method, and then calls the call on another thing, creating a chain of 'call' method calls. Call call? Call. Call call call. But yes, if you play with that more directly, you can clearly describe which objects feed in to each other, and have the session middleware at a more outer layer than your own middleware. Usually this ends up looking like: run OuterMostMiddleware.new(MiddleMiddleware.new(InnerMiddleware.new(SomeCampingApp))) Each layer wraps around the outside of the next, so the message from a web request travels in left to right along this line, then the response travels back right to left as each 'call' method on the middleware objects finish their work and return to the next layer leftward. — Jenna Fox On Monday, 2 January 2012 at 10:10 PM, Daniel Bryan wrote: I'm trying to implement some simple middleware that will have behaviour based on session data. From looking at the source for Camping::Session and Rack::Session, I thought I'd just be able to put my own middleware between Camping::Session and my app. I tried doing it the same way that Camping::Session works - by including a module in my app - but if I inspect the environment in there, it's still encrypted. Has anyone else tried something like this? ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Mab: The tiny Markaby-alternative
Do we want a brand new markaby-like thing to be the grand evolution of Why and Tim's initial creation, or do we want to stand out and say Hey world, we've made something like Markaby, but heaps better, in the way the Nokogiri clan have. I've changed my mind. I think it should have a new name. Why’s legacy serves only as a distraction, lets move on. I suggest for your consideration: Pagely — Jenna Fox On Tuesday, 20 December 2011 at 7:36 PM, Magnus Holm wrote: 2011/12/19 Bartosz Dziewoński matma@gmail.com (mailto:matma@gmail.com): 2011/12/19 Magnus Holm judo...@gmail.com (mailto:judo...@gmail.com): The real question here is: Should it be a part of camping/mab.rb or the Mab-gem? I'm definitely for adding many features (indentation, attribute-validation, flow-validation), but not in Camping. The Camping implementation should just be enough to get you started. My suggestion would be to make it Markaby 2.0 (of course, once it's running and mostly backwards-compatible), keeping the old gem name, and to develop on a branch in markaby repo. I'm really not sure about keeping the name though. It feels kinda weird to just remove everything and start from scratch. I also don't think it's a good idea to duplicate functionality - a little stub with Camping, richer library elsewhere - just make it a dependency, like Isak says. Okay, no stubs. Either hard or soft dependency. ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Camping Server: automatically serve static files from public/
I vote number 2 - it keeps apps separated, so you can pop a whole bunch in a folder and call it a day - Having one big shared public folder is messy and breaks that model of separation entirely. If people like Isak have existing arrangements in place, there aught to be some configurable option to specify any arbitrary folder as the public files. — Jenna Fox On Tuesday, 20 December 2011 at 9:19 PM, Paul van Tilburg wrote: On Tue, Dec 20, 2011 at 11:06:09AM +0100, Isak Andersson wrote: I think Alternative 2 makes the most sense. Then you can have multiple apps that don't share the public folder. Plus, you put almost everything in the app folder anyways so there shouldn't be a difference now either. Alternative 2: app.rb app/public app/public/style.css # example I disagree. In most cases there is only one app (at least for most of my apps). So I have an app.rb with stuff under public/. If there are more apps, there is no way of knowing whether they are designed to work together and share the same public data, or they are apps with seperate(d) public data. Since one has to build the URLs in the app anyway, why not let the developer decide the layout of public/ to suit a shared or seperated layout? (One can think of shared stylesheets, but different sets of icons/PDFs/whathaveyou). Kind regards, Paul -- Web: http://paul.luon.net/home/ | Email: p...@luon.net (mailto:p...@luon.net) Jabber/GTalk: p...@luon.net (mailto:p...@luon.net) | GnuPG key ID: 0x50064181 ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Markaby license issue
XHTML5 is a fancy name for the way the HTML5 spec grudgingly allows the use of XML-like syntax, allowing for XML Builders like current markaby to be technically allowable as valid HTML. It's not 'real' in that they don't provide validators for it and browsers aren't supposed to parse it as XML or support any XML features. The HTML spec suggests it be avoided if possible, and I agree, on the grounds that XML-style syntax gives people the incorrect impression that a document maybe valid XML. In most cases, that's not true. It might also give people the impression that they could use XML features, which is also not true. XHTML is a dead standard. Long live HTML with XML-style boolean attributes and self closing tags permitted! And long live Nokogiri/Beautiful Soup - the easy and friendly way to parse any sort of document, regardless if it pretends to be XML or is just plain friendly compact HTML. — Jenna Fox On Tuesday, 20 December 2011 at 10:09 AM, Dave Everitt wrote: Small note: XHTML did survive, it's XHTML2 which didn't: there's an XML version of HTML5 called XHTML5. We now return to your regularly scheduled discussion. I didn't know about XHTML5 and can't find any recent information? - DaveE ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Mab: The tiny Markaby-alternative
Nah I'd still just think I want camping! I'll install camping! but then it'd just work :P — Jenna Fox On Tuesday, 20 December 2011 at 1:15 PM, David Susco wrote: So then I'd have to remember it's the opposite of the way it's been? :P Dave On Mon, Dec 19, 2011 at 5:53 PM, Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) wrote: If no hard dependancies, can we switch it around so core camping is in a camping-seedling gem, and the regular camping gem is actually the one with all the omnibus? I always forget when setting up a new system and end up confused why camping isn't working — Jenna Fox On Tuesday, 20 December 2011 at 9:52 AM, Dave Everitt wrote: switch to a hard dependency on Markaby, or should we continue what we're doing today? no hard dependency, continue as today - DaveE ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list -- Dave ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Markaby license issue
I tried to use that crazy stuff recently and it just doesn't work, in webkit at least. — Jenna On 20/12/2011, at 4:34 PM, Steve Klabnik st...@steveklabnik.com wrote: Yep! Granted, if you serve it with an XML MIME type, it must be able to be parsed with an XML parser, so none of that p bthis iis/b insane/i stuff! But still... I actually like XML. There are some of us in Ruby... ___ 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: Markaby license issue
Aw..
That is rather disappointing. But still, I see this problem as a chance to be
reborn anew. Fresh and clean of the bad lessons learnt by Markaby. We did learn
some lessons, didn't we?
—
Jenna Fox
On Sunday, 18 December 2011 at 7:27 PM, Magnus Holm wrote:
On Sun, Dec 18, 2011 at 02:47, Steve Klabnik st...@steveklabnik.com
(mailto:st...@steveklabnik.com) wrote:
A wild project appears: http://krainboltgreene.github.com/dapper-dan/
Some problems:
* It doesn't support CSS proxy (div.wrapper! { … ] == div(:id =
'wrapper') { … })
* It doesn't escape stuff
* It doesn't specify its dependencies correctly (crack.rb)
* It loads awesome_print at runtime
* The released version on RubyGems doesn't actually work
Everything else than the first issue is easy to fix. CSS proxies might
require some bigger refactoring to implement.
That said, it's not hard to implement something Markaby-ish. I
experimented a bit, and ended up with a fast Markaby-replacement in
130 LoC: https://github.com/judofyr/rumble. We might be able to adapt
it.
___
Camping-list mailing list
Camping-list@rubyforge.org (mailto: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: setting controllers etc
sit there and write a module for each one?
You mean, type 'MyApp::Controllers::'? You could make it simpler by adding a C
= MyApp::Controllers line before your controller requires, then you could write
'class C::Whatever R('/url')' sort of stuff.
I really don't like the magic of set :views so far as it's interaction with
markaby. Maybe I objected when it was added. If not, I mustn't have been paying
much attention. One of Camping's major selling points is that it's just
straight forward ruby classes and modules. No magic. Magic is anything where
you don't immediately fully grasp how it works. set :controllers is that type
of thing. Is it filename based? Where do you specify URL rules? Can you have
one controller inherit from another? Can you mixin modules to get useful
methods? How do helpers work?
None of those things are clear, when writing set :controllers (or set :views
for that matter!), which means explaining them in docs or by reading camping's
source code, which means memorising more new facts you don't really need to
know, wasting everyone's time, and distracting you from the app you're
intending to build.
—
Jenna Fox
On Monday, 19 December 2011 at 9:50 AM, icepa...@lavabit.com wrote:
Sure, but say that you want to have lots and lots of controllers, I don't
think anyone wants to sit there and write a module for each one to be
honest.
And with that way of thinking we shouldn't even be able to set :views. We
would have to write a module App::Views for every view.
set :views is magic, but it is not a bad kind of magic. This is just basic
stuff to make a web app pleasant to develop.
And I know set :views is partially so we can use any markup engine we
want. But not being able to do the same for all the others is silly in my
humble opinion.
Compared to things found in rails it doesn't even come close to magic
where you have no clue of what's going on or how it works. It's not like
you have to take it even if you don't want it either. You have to set it
yourself, and that eliminates the feeling of magic for me.
The regular way of doing this with requires is simply that your
'controller' files look like this:
module MyApp::Controllers
class PonyX
def get id
.. logic to look up pony with id ..
end
end
end
This can even be generalized further I expect, to
class MyApp::Controllers::PonyX
…
end
This way you totally avoid weird evaling hacks, and are just writing plain
old straight forward ruby code with no magic (as is the Camping way). It
works because camping allows you to reopen modules and classes again and
again by defining them several times, adding new classes or adding new
methods to existing classes.
—
Jenna Fox
On Monday, 19 December 2011 at 8:56 AM, icepa...@lavabit.com
(mailto:icepa...@lavabit.com) wrote:
What I am doing now is basically the same as requiring. If I do require
with all the files, they don't become a part of the controllers module.
The problem is that having to require (or in my case 'add') ever
controller is *not* a very good way to work. It would be much better to
be
able to just do:
set :controllers, *path to controllers*
Because in the long run, that saves you time, and a bunch of boring and
tedious work.
The problem isn't that the solution I currently have doesn't work, this
is
just a suggestion to make Camping so much better.
I don't think I understand the problem - can't you just `require` all
the files with controllers?
-- Matma Rex
___
Camping-list mailing list
Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
http://rubyforge.org/mailman/listinfo/camping-list
Find aldi jobs Online Get Started Now.
http://click.lavabit.com/db5fe7a9kai9wirqj77kjjiskdphxcqqrdiye5hkpuyeyn1bah8y/
___
Camping-list mailing list
Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
http://rubyforge.org/mailman/listinfo/camping-list
Learn How To Get Your Certification Training As A Radiology Technician.
http://click.lavabit.com/5rmgod5iesh68xxeayxmjfqgo5fc3dqbm7m94shsxktoioehr3cb/
___
Camping-list mailing list
Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
http://rubyforge.org/mailman/listinfo/camping-list
Re: Markaby license issue
Nice! Lets just all use this thing! What say you, everyone? — Jenna Fox On Sunday, 18 December 2011 at 12:47 PM, Steve Klabnik wrote: A wild project appears: http://krainboltgreene.github.com/dapper-dan/ ___ Camping-list mailing list Camping-list@rubyforge.org (mailto: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: Riak on Camping
You can't use ActiveRecord with map-reduce databases anyhow, without loosing a bunch of performance and features. It's best to use a specialised adaptor just for Riak. It looks a bit similar to CouchDB, so you might also like to have a look at that if you can't find any good rubygems for riak. CouchDB supports all that delicious p2p replication stuff too, sans the weird 'enterprise' version with extra withheld features. — Jenna On 07/12/2011, at 7:26 AM, Isak Andersson wrote: Good day, does anyone here have a clue on how to make use of the NoSQL database Riak with Camping? I am building my website and Riak seems like pretty much the ultimate database! This would probably ruin every little feature in ActiveRecord, I don't think I'd be able to do any has_many's or belongs_to but I'd LOVE to be proven wrong. As far as I know (but maybe I should do some research before saying it) there isn't any adapter for Riak yet. I want to use it anyways though, connecting nodes around the globe! |m| -Isak Andersson TLB -- Using the Opera email client: http://www.opera.com/mail/ ___ 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: Riak on Camping
I can deploy that update to whywentcamping later. — Jenna On 07/12/2011, at 10:09 AM, Isak Andersson wrote: Nah, that's what I imagined. CouchDB indeed seems a lot like Riak but I think I'm gonna stick to Riak as it is attractive somehow! There seems to be some rubygems one that is only 0.0.1 :/ which is an adapter. And another one called riak-client which seems to be the most relevant one. Looking in the documentation sure makes it look right. It gave me the impression first that it was some ruby reimplementation of Riak first (which would be kind of dumb) but it's a toolkit. It uses something called Ripple which has an ActiveModel compatible modeling layer inspired by ActiveRecord, DataMapper and MongoMapper. Now I don't know if that means it's possible to go has_many etc. I guess we'll see when I start using it! Thanks for your help! Also (not relevant) I fixed the CSS for whywentcamping.com (at least it should be fixed) to be compatible with Opera browser. It is pushed to the Github repo, all we really need to do is to update the code for the actual site. I have no idea on how to do that, someone who knows should probably look in to that. Then I can finally go to the site without having to switch browser ;) Cheers! Isak Den 2011-12-06 23:23:47 skrev Jenna Fox a...@creativepony.com: You can't use ActiveRecord with map-reduce databases anyhow, without loosing a bunch of performance and features. It's best to use a specialised adaptor just for Riak. It looks a bit similar to CouchDB, so you might also like to have a look at that if you can't find any good rubygems for riak. CouchDB supports all that delicious p2p replication stuff too, sans the weird 'enterprise' version with extra withheld features. — Jenna On 07/12/2011, at 7:26 AM, Isak Andersson wrote: Good day, does anyone here have a clue on how to make use of the NoSQL database Riak with Camping? I am building my website and Riak seems like pretty much the ultimate database! This would probably ruin every little feature in ActiveRecord, I don't think I'd be able to do any has_many's or belongs_to but I'd LOVE to be proven wrong. As far as I know (but maybe I should do some research before saying it) there isn't any adapter for Riak yet. I want to use it anyways though, connecting nodes around the globe! |m| -Isak Andersson TLB -- Using the Opera email client: http://www.opera.com/mail/ ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list We compare the best offers just for U. Our top 5 selection. Take the chance to make a good deal! http://click.lavabit.com/nu7xj7eg4a6p6obzf97i5765y7qxrprs8m4xuj7zwdcn96x9uu5b/ -- Sent from Opera web browser. http://www.opera.com/mail/ ___ 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: Markaby + HTML5
If you add the line '@auto_validation = false' to the beginning of your layout, markaby aught to stop minding if you use things unspecified in xhtml. I'm not too sure if that will let you use unknown tags, or just unknown attributes. If you have any trouble getting unknown tags to work, try using the tag! method: tag! 'footer', arg, arg, arg… effectively is a more explicit and direct version of: footer arg, arg, arg… Hope that helps! Hopefully we'll have a html5-friendly markaby soon. :) — Jenna On 05/11/2011, at 11:22 PM, Nokan Emiro wrote: Hi, this is not really a Camping question, but a Markaby one, so please don't be angry, please! :) How can I use HTML5 tags (for example footer) and HTML5 compliant attributes (for example data-content=xxx) in Markaby? It throws an error when I try this. I've workarounded it with text footer and text div data-content=\xxx\ but this isn't the nicest solution. How would you do these? u. ___ 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: run my Camping app as a Rack app
It looks as if your application is getting a FastCGI request without the 'PATH_INFO' environment variable. I'm not too sure what to make of that. Can you try a rackup which runs this app? require 'rack' require 'pp' App = lambda do |env| body = '' PP.pp env, body [200, 'Content-Type' = 'text/plain', body] end Rack::Handler::FastCGI.run App, :Port = 9000 and let us know what it prints out as being in the environment. Maybe your webserver doesn't provide PATH_INFO over FastCGI. If that's the case, we'll need to consider how we can be compatible with that. — Jenna On 10/10/2011, at 6:24 AM, Nokan Emiro wrote: The app itself implements Rack protocol. Yes, that's what I've already tried. It is the case when my app stops whenever the first fastcgi request arrives: /usr/lib/ruby/1.8/rack/utils.rb:23:in `unescape': undefined method `tr' for nil:NilClass (NoMethodError) from (eval):33:in `call' from /usr/lib/ruby/1.8/rack/session/cookie.rb:37:in `call' from (eval):38:in `call' from /usr/lib/ruby/1.8/rack/content_length.rb:13:in `call' from /usr/lib/ruby/1.8/rack/handler/fastcgi.rb:57:in `serve' from /usr/lib/ruby/1.8/rack/handler/fastcgi.rb:25:in `run' from /usr/lib/ruby/1.8/rack/handler/fastcgi.rb:24:in `each' from /usr/lib/ruby/1.8/rack/handler/fastcgi.rb:24:in `run' ... What I do here is: require 'camping' require 'camping/session' Camping.goes :App module App # . here is my Camping App end Rack::Handler::FastCGI.run App, :Port = 9000 ...and configure webserver to send fcgi queries to 9000. Is this a Rack problem? (In this case I'm sorry bothering you!) uzlee ___ 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
Simplest easiest rss feeds?
I'm looking to make rss feeds of some of my controller data - what's the simplest way to render some? Is there some way I can feed a json-like arrays of hashes type of structure in to some gem and get out an xml feed? Would it be more of a builder sort of operation? — Jenna ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Simplest easiest rss feeds?
So there is! Thanks Steve! — Jenna On 05/10/2011, at 12:48 PM, Steve Klabnik wrote: There's an RSS generator in the standard library. ___ 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: Maintenance release of 2.1
True that. Meanwhile, have you guys seen http://twitter.github.com/bootstrap/ ? It looks pretty nice, and I imagine something like that could be pretty powerful if deeply integrated with a version of markaby, as a 'ui toolkit for the web' sort of thing - a nice sensible clean default style for quickly prototyping ideas, and teaching beginners the concepts of the web. — Jenna On 03/10/2011, at 8:47 PM, Magnus Holm wrote: On Sun, Oct 2, 2011 at 14:26, Jenna Fox a...@creativepony.com wrote: I wouldn't bother with reducing the revision number. If anything having weirdly high ones makes the project seem more alive and active. Is the minor number even functionally useful here? Maybe we should ditch that and just keep major as a look! An increment! Heaps cool stuff must have happened! unless google chrome has ruined new major numbers for everyone anyway. Well, it's useful for computability reasons. Every app created on 2.x should work on 2.x+n with minimal required changes. ___ 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: Maintenance release of 2.1
Oh right, but you can use that LESS thing I think to compile the bootstrap properties in to your regular CSS, so you keep using good quality selectors, and bootstrap essentially augments your CSS with useful macros. Another way to do it is to define markaby helpers for each kind of thing, so you can still just go change one small piece of code to restyle the whole site's whizlebobs. — Jenna On 04/10/2011, at 3:07 AM, Bartosz Dziewoński matma@gmail.com wrote: Personally I hate it. It's like table border=2 and font size=7 once again, except this time camouflaged as CSS classes. The only good things in there are either styled pretty much the same way by default (like, say, headers), or require a line of code (@basefont, layouts). -- Matma Rex 2011/10/3 Jenna Fox a...@creativepony.com: Meanwhile, have you guys seen http://twitter.github.com/bootstrap/ ? It looks pretty nice, and I imagine something like that could be pretty powerful if deeply integrated with a version of markaby, as a 'ui toolkit for the web' sort of thing - a nice sensible clean default style for quickly prototyping ideas, and teaching beginners the concepts of the web. ___ 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: Teaching
Great! If you'd like help with anything you know where to come. :D On 02/09/2011, at 9:17 AM, Anonymous Waffles wrote: I don't think I know enough to contribute anything, but I'll see if I could perhaps write up something from what I learn here, perhaps making it more user-friendly. -Waffles On Wed, Aug 31, 2011 at 6:11 PM, Jenna Fox a...@creativepony.com wrote: Would you like to write some content for it Waffles? The version at http://whywentcamping.com/The-Camping-Book is a wiki - you can edit it by clicking the pencil, though you need a github account as it's a mirror of the camping/camping github wiki On 01/09/2011, at 9:21 AM, Anonymous Waffles wrote: I would personally like to see the Camping book expanded on more, but I can't wait to see some more projects for spreading Camping. -Waffles On Wed, Aug 31, 2011 at 10:02 AM, Dave Everitt dever...@innotts.co.uk wrote: Everyday is WhyDay. You should know this! :D oh yeh - I forgot :-) I'll email you directly with infos later. k ___ 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 ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Teaching
Everyday is WhyDay. You should know this! :D I'll email you directly with infos later. — Jenna On 31/08/2011, at 9:38 PM, Dave Everitt wrote: I think there's nothing more fun than finding noobs and teaching them how to make awesome hacks! I know some of you guys think like I do, and I want to know which ones of you that is? I'm one of those. I've a project in mind, and it's going to take some doing. I could do it myself, but it'd be way better with a bunch of total geniuses at the helm than just silly old me. how about drawing on the wisdom of multiple silly old mes? I'm no uber-specialist, but I do have a good understanding of the difficulties people have with this stuff. With a stupid number of projects on the go, I'm not promising anything, but what's the idea? It's probably time for someone to make a new Camping screencast... So seeing as today is WhyDay and all, it seems like we should be thinking about the kids, and about teaching, and about drawing pictures of little silly people talking about silly things which somehow leads to education through nothing more than a thick coating of irrelevance. (I thought WhyDay was August 19th?) now that's one of the reasons I joined this list - I wanted to use Camping as a way of introducing students to the next step after HTML/CSS. In the end, I only ever had on who was interested. TL;DR; I want brains. Braains http://cl.ly/0i1Q3S0A1017470j2c2r lol DaveE ___ 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: Teaching
Would you like to write some content for it Waffles? The version at http://whywentcamping.com/The-Camping-Book is a wiki - you can edit it by clicking the pencil, though you need a github account as it's a mirror of the camping/camping github wiki On 01/09/2011, at 9:21 AM, Anonymous Waffles wrote: I would personally like to see the Camping book expanded on more, but I can't wait to see some more projects for spreading Camping. -Waffles On Wed, Aug 31, 2011 at 10:02 AM, Dave Everitt dever...@innotts.co.uk wrote: Everyday is WhyDay. You should know this! :D oh yeh - I forgot :-) I'll email you directly with infos later. k ___ 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: A question about the ecosystem.
Hi Tim! Camping is a great choice. It's really lean, and quite robust and well performing. So far as rails plugins go - the default choice of database adaptors for Camping is ActiveRecord - so most ActiveRecord-related rails plugins will work. Camping doesn't have things like rail's form builders and validators and the likes, and it also doesn't have activesupport. You might find that installing the activesupport gem and requiring it at the start of your app makes more rails specific code work, by adding in support for things like String#ends_with? Overall, there really isn't very much to miss. Camping provides what you need of controllers and views, while the outer shell of rack provides extras you might like. A sampler box of rack features might have some of these: Several flavours of session storage and cookies - including the fastest variety, used by the likes of google and yahoo; Stream compression filters, to gzip whatever you send out, streamlining cinematic immersion and minimising wasted bytes; http validators; html validators; url mapping to bundle several camping apps together in to one; the option of picking and choosing - you can use camping for some of your app and rails or any of the rest for another part. I suppose the best feature of camping is the community though. If there's anything you need there's surely someone happy to help. — Bluebie On 30/08/2011, at 8:40 PM, Tim Uckun wrote: I am a long time rails developer looking for a new framework which is leaner and less complex than rails. Camping appeals to me for a lot of reasons but I am curious about how a moderately conplex app would look like in camping. In rails my Gemfile is full of third party libraries and I am wondering if they will all (or most) work with camping. My guess is that they won't and I am worried that I will have to code up all kinds of functionality I take for granted in the rails world. Maybe that's a good thing but I wanted to ask you guys about your experience in taking advantage of other people's work. Cheers. ___ 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: Help with Controllers
That's great that you're learning a new language. I really hope you have tons of fun and make a whole lot of neat stuff. Keep us posted, kay? On forms: The :action property is optional - if you omit it, it'll submit the form to the same URL you're currently on in your web browser. You use R() in the action just like you'd use it on an a(:href = R(…)) link. The thing about PageX, is that it takes one thing with it, the X - so it's urls look like /page/something/, and you kind of need to tell it what the something is. If you make a controller called, say, class MyCoolStuff; then you can just :action towards R(MyCoolStuff) and that'll be that. I hope that clears things up a bit. — Bluebie On 30/08/2011, at 1:47 PM, Anonymous Waffles wrote: Hello guys, I'm new to the Ruby, and especially to Camping. I've been having some difficulty because there aren't that many tutorials about Camping compared to other larger frameworks. I've been building some small stuff recently to learn about how it work, but I've puzzles as to how user input in a textbox is processed. Here's some code from the awfully short yet extremely informative Camping Book: module Nuts::Views def edit h1 @page.title form :action = R(PageX, @page.title), :method = :post do textarea @page.content, :name = :content, :rows = 10, :cols = 50 br input :type = :submit, :value = Submit! end end end It's apparent that since the input is encased in the textarea block, it send the value when clicked. the :action says what class to send it to, and :method which method. The docs say that the R() syntax is for creating a path. Could I simply use the name of a controller instead, if it's in the same Ruby file? And how is it sent along? Must the post method have a certain argument? If somebody could answer my questions it would be extremely appreciated. -Waffles ___ 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: Advice on strategy for maintaining state in Camping
Hold up guys. This is a little web app for just you to use? not multiple users? Depending on how you deploy camping you can just stick some stuff in some class variables if you just need them in one controller, or even global variables if you want them in many places. Then all you'd need to do is boot a local copy with The Camping Server and do your things. The objects will just stay in ruby's memory because unlike cgi apps or things like PHP, ruby web apps don't flush their global scope reload on every request. Wouldn't that be the ridiculously easy and straight forward way to solve this? — Jenna On 26/08/2011, at 7:33 AM, Anders Schneiderman wrote: Thank you so much Magnus and David for your speedy advice! Magnus, I think you're right a SQLlight database seems like the best way to go. Cool! Is easier to manage web apps than native apps using NaturallySpeaking, or is it just the the native window-based UIs are way too complex? I've never really optimized a web app for accessibility (which is pretty terrible when I think about it)? It's a bit of both. NaturallySpeaking tries to make their software as Web-friendly as possible, so, for example, if I display the fields I want to be able to choose as a bunch of hyperlinks in a on the page, I can click any of them by voice as I could any link on a webpage. With wxruby, that's not the case. And since I've done a lot of HTML/CSS work in past jobs, I can bang it out a lot faster than learning wxruby or some other UI – and it's a lot easier to build something that has a little style to it. :) Thanks very much! Anders ___ 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: Feature: Simple controllers?
I vote revert. This is just sinatra - I feel it's important camping maintains the cleanliness and clarity of functionality given to us by using simple classes. It's something we have which AFAIK no other ruby web framework does - you know exactly how it works, because it's just a class. On 26/08/2011, at 7:21 AM, Magnus Holm wrote: On Aug 25, 2011 10:54 PM, John Beppu john.be...@gmail.com wrote: If I wanted that notation, I'd just use Sinatra. ;) Like Bartosz, I like having named controllers so that I can pass them to R() when generating links. Does it make it better that you can name them too? Index = get / do ... end Sent from my iCampingPhone ___ 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: Did not know you could provide a list of urls in a controller route declaration
Good for maintaining legacy URLs. :) —Jenna / @Bluebie On Thursday, 10 February 2011 at 11:51 AM, Tony Miller wrote: On Fri, Feb 04, 2011 at 05:37:55PM -0700, Philippe Monnet wrote: class Welcome R '/welcome', '/WelcomeEveryone' end What does this mean, that '/welcome' and '/WelcomeEveryone' will use the exact same controller? How is that useful? -Tony ___ 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: controller for all javascript files?
class LoadScript R '/(.*).js'
def get(script)
@headers['Content-Type'] = 'text/javascript; charset=utf-8'
return File.read(my scripts/#{script}.js);
end
end
Keep in mind the R constructor takes a regexp, and passes the bracketed
sections as arguments to the get, post, put, etc... methods on the class when
called.
—Jenna / @Bluebie
On Thursday, 10 February 2011 at 11:54 AM, Tony Miller wrote:
I want to use the same controller for every javascript file...so I was
thinking something like this? What I'm not sure of is what to pass to
File.read.
class Javascript R '/*.js'
JS = File.read()
def get
@headers['Content-Type'] = 'text/javascript; charset=utf-8'
JS
end
end
Is there a better way to do this? I was looking at adam's project:
https://github.com/minikomi/tokyoartparties/blob/master/src/Drinking.rb
and I didn't see a controller for his css, so I'm kind of wondering
how he does it...
Thanks,
-Tony
___
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: controller for all javascript files?
Glad I could help. :)
—Jenna / @Bluebie
On Thursday, 10 February 2011 at 2:53 PM, Tony Miller wrote:
Thanks Jenna, this works great! I think I understand how the R
constructor works a little more now...
On Wed, Feb 9, 2011 at 5:23 PM, Jenna Fox a...@creativepony.com wrote:
class LoadScript R '/(.*).js'
def get(script)
@headers['Content-Type'] = 'text/javascript; charset=utf-8'
return File.read(my scripts/#{script}.js);
end
end
Keep in mind the R constructor takes a regexp, and passes the bracketed
sections as arguments to the get, post, put, etc... methods on the class
when called.
—
Jenna / @Bluebie
On Thursday, 10 February 2011 at 11:54 AM, Tony Miller wrote:
I want to use the same controller for every javascript file...so I was
thinking something like this? What I'm not sure of is what to pass to
File.read.
class Javascript R '/*.js'
JS = File.read()
def get
@@headers['Content-Type'] = 'text/javascript; charset=utf-8'
JS
end
end
Is there a better way to do this? I was looking at adam's project:
https://github.com/minikomi/tokyoartparties/blob/master/src/Drinking.rb
and I didn't see a controller for his css, so I'm kind of wondering
how he does it...
Thanks,
-Tony
___
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
Re: ABingo (A/B Testing framework) plugin for Camping
O_O — Jenna / @Bluebie On Tuesday, 25 January 2011 at 12:21 AM, Dave Everitt wrote: Hi Jenna - just checking email backlog, was going to pop something up on Phillippe's behalf, but Rack is down on whywentcamping.com :-( - Dave Everitt Hey you know it would be totally awesome if you did some posts on the camping blog at http://log.whywentcamping.com/submit about this neat stuff so we can mutually bask in whatever minor exposure that might bring. :) Give me a poke if you submit something through that so I can hit publish on the tumblr end. j On 16/12/2010, at 15:47, Philippe Monnet r...@monnet-usa.com wrote: I posted part II of the series, detailing the steps to add ABingo to a test Camping app - http://blog.monnet-usa.com/?p=330 GitHub and RubyGems have been updated with a couple changes too. There is also a very basic example at http://camping- abingo.heroku.com/ On 12/2/2010 5:34 PM, Philippe Monnet wrote: After becoming interested in Patrick McKenzie's ABingo A/B testing framework for Rails I decided to adapt it for Camping after getting his blessing. The plugin can be found on GitHub at: https://github.com/techarch/ camping-abingo The camping-abingo gem is on RubyGems. The doc is at: http://camping-abingo.monnet-usa.com/ And I started the first of a couple posts on ABingo for Camping: http://blog.monnet-usa.com/?p=322 Philippe (@techarch) PS - for the moment I have not promoted the repository up to the Camping GitHub org but I can do that if people feel like it should be there. ___ 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: ABingo (A/B Testing framework) plugin for Camping
Okay fixed. For now. *curses at shared hosting provider changing stuff!* — Jenna / @Bluebie On Tuesday, 25 January 2011 at 9:07 AM, Jenna Fox wrote: O_O — Jenna / @Bluebie On Tuesday, 25 January 2011 at 12:21 AM, Dave Everitt wrote: Hi Jenna - just checking email backlog, was going to pop something up on Phillippe's behalf, but Rack is down on whywentcamping.com :-( - Dave Everitt Hey you know it would be totally awesome if you did some posts on the camping blog at http://log.whywentcamping.com/submit about this neat stuff so we can mutually bask in whatever minor exposure that might bring. :) Give me a poke if you submit something through that so I can hit publish on the tumblr end. j On 16/12/2010, at 15:47, Philippe Monnet r...@monnet-usa.com wrote: I posted part II of the series, detailing the steps to add ABingo to a test Camping app - http://blog.monnet-usa.com/?p=330 GitHub and RubyGems have been updated with a couple changes too. There is also a very basic example at http://camping- abingo.heroku.com/ On 12/2/2010 5:34 PM, Philippe Monnet wrote: After becoming interested in Patrick McKenzie's ABingo A/B testing framework for Rails I decided to adapt it for Camping after getting his blessing. The plugin can be found on GitHub at: https://github.com/techarch/ camping-abingo The camping-abingo gem is on RubyGems. The doc is at: http://camping-abingo.monnet-usa.com/ And I started the first of a couple posts on ABingo for Camping: http://blog.monnet-usa.com/?p=322 Philippe (@techarch) PS - for the moment I have not promoted the repository up to the Camping GitHub org but I can do that if people feel like it should be there. ___ 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: [ANN] ABingo (A/B Testing framework) plugin for Camping
Hey you know it would be totally awesome if you did some posts on the camping blog at http://log.whywentcamping.com/submit about this neat stuff so we can mutually bask in whatever minor exposure that might bring. :) Give me a poke if you submit something through that so I can hit publish on the tumblr end. j On 16/12/2010, at 15:47, Philippe Monnet r...@monnet-usa.com wrote: I posted part II of the series, detailing the steps to add ABingo to a test Camping app - http://blog.monnet-usa.com/?p=330 GitHub and RubyGems have been updated with a couple changes too. There is also a very basic example at http://camping-abingo.heroku.com/ On 12/2/2010 5:34 PM, Philippe Monnet wrote: After becoming interested in Patrick McKenzie's ABingo A/B testing framework for Rails I decided to adapt it for Camping after getting his blessing. The plugin can be found on GitHub at: https://github.com/techarch/camping-abingo The camping-abingo gem is on RubyGems. The doc is at: http://camping-abingo.monnet-usa.com/ And I started the first of a couple posts on ABingo for Camping: http://blog.monnet-usa.com/?p=322 Philippe (@techarch) PS - for the moment I have not promoted the repository up to the Camping GitHub org but I can do that if people feel like it should be there. ___ 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: Couldn't load the feed. oh well.
Yeah, I noticed that today too. Thanks for the heads up. Will get it sorted soon. — Jenna / @Bluebie On 09/12/2010, at 3:39 PM, Steve Klabnik st...@steveklabnik.com wrote: Hey Campers- Just a small note, I went to http://whywentcamping.com/ today, and it's saying *Latest news: **Couldn't load the feed. Oh well.* Figured you might like to know! -Steve ___ 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: Couldn't load the feed. oh well.
Seems to be working now, so I'm just going to wave my hand and declare it to all be to do with tumblr's recent downtime problems, somehow. :S — Jenna / @Bluebie On Thursday, 9 December 2010 at 3:27 PM, Steve Klabnik wrote: Hey Campers- Just a small note, I went to http://whywentcamping.com/ today, and it's saying Latest news: Couldn't load the feed. Oh well. Figured you might like to know! -Steve ___ 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: Oh, whywentcamping.com!
Actually I realised about half way through making the thing, GitHub has a syntax for highlighted code. It looks like this: ```ruby Camping.goes :Poop ``` So we could use that instead, would be easy enough. Seems a kind of ugly syntax though On 25/08/2010, at 1:39 AM, Magnus Holm wrote: Awesome work, Jenna :-) One issue: The code blocks doesn't show properly on GitHub: http://github.com/camping/camping/wiki/Book:-Getting-Started Not sure what's the best way to handle this. We should at least indent all the code blocks with 4 spaces (so they end up as Markdown pre tags), and somehow tag them as Ruby for whywentcamping.com We should probably update the RDoc template at camping.rubyforge.org, but I'm also open for re-thinking the reference section all-together. Is it really useful in its current form? // Magnus Holm On Tue, Aug 24, 2010 at 15:31, Jenna Fox a...@creativepony.com wrote: I'm feeling pretty happy about the state of the website now! http://whywentcamping.com/ And the blog to go with it http://log.whywentcamping.com/ What's the next thing? work on the api reference? write more content? Is there any other camping stuff which would benefit from my dodgy doodling attentions? — Jenna ___ 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 Writing Requests!
Wonderful! I've ported over The Camping Book as well. Is there anything else we need sorted quickly? I'm not sure what to do about the 'reference' rdoc thingo. It seems kind of difficult to navigate to me - camping is one of the few projects I frequently read the source code of instead of web docs. Not sure really what could be done about that though. Perhaps some kind of more app-like web thing, for browsing the rdocs, with a little fulltext search widget and stuff like that would be nice? Though I suppose if going to all that trouble, it might as well be a generic ruby thing. Maybe I should build a ruby docs browser website, capable of loading in docs from core, std, and any gem. Maybe camping would benefit from having a sample library? Something akin to the Shoebox, where little tiny but essentially complete fun apps would be available for live pokings as well as having their source code exposed and easily downloadable in a zip or something? That would integrate really well with Judofyr's online editor whosits. I wonder if we could get that jRuby-powered applet demo doodad running camping apps in the mean time, until editor stuff, or, alternatively, someone know where we can get a VM for running insecure code? — Jenna On 22/08/2010, at 11:30 PM, Dave Everitt wrote: Hi Jenna - done (Markdown). Others can add to it now - Dave E. Heya! So I'm trying to get this new website all tied up in a nice little bunch. I'm a bit silly when it comes to git-fu though. Could one of you create a page on the camping/camping wiki called 'Contributing', and put stuff in it which tells people how to do that? Use Markdown or Textile. Doesn't really matter which. I'm moving most of the articles I work on over to Markdown because textile and my brain don't like each other and I don't much like being stuck in the middle of their squabbles. Do whatever though. ___ 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: Philosophy
http://github.com/camping/camping/wiki/Philosophy Whatcha guys think? — Jenna ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: What is the process for publishing to campingrb.tumblr.com?
Why would you want to recreate the camping framework? It already exists. Is there some feature or change we could make which would make camping more suitable for your needs? — Jenna On 23/08/2010, at 12:17 PM, Angel Robert Marquez wrote: would you all walk me through how to create a camping esque framevork from scratch or point me in the right direction? help me creative pony, PM you're my only hope. On Sun, Aug 22, 2010 at 6:18 PM, Jenna Fox a...@creativepony.com wrote: All invited now. On 23/08/2010, at 9:43 AM, Philippe Monnet wrote: It would be great if you could add the various members of the Camping organization on GitHub once they create an account on Tumblr. I just created mine: techarch.tumblr.com Philippe (@techarch) On 8/22/2010 4:59 PM, Jenna Fox wrote: Create an account on tumblr.com, then visit http://campingrb.tumblr.com/submit and submit your post in to the log's publishing queue. One of the log's members will then check and approve it. People who contribute a couple of good posts will likely be given membership in the blog, letting you skip the queue. On 23/08/2010, at 12:55 AM, Philippe Monnet wrote: In the future when we have updates/announcements related to Camping, how will we be able to publish them to the Tumblr blog? ___ 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 ___ 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: Need input on proposed tweaks to www.ruby-camping.com
Bartosz Dziewoński wrote: Windows XP, Opera 10.61 (newest stable), 1024x768. It looks similar in Firefox 3.6 (http://imgur.com/atSts.png). Yeah. It's an artefact of Microsoft's plainly terrible type engine. I'm not sure how to fix it or even if it's possible to fix it, short of manually fattening up the typeface and User-Agent sniffing to serve differently weighted typefaces to Microsoft platforms. There are tons of things which are more important to me than making a custom typeface just to work around windows 'features'. I'll keep pondering for now. Also, the header breaks in Firefox - the fills do not fit the outlines: http://imgur.com/cJXoq.png I'm aware of this issue and I fixed it in github yesterday (!) and sent a pull request to Judofyr, however it hasn't been pushed yet to rubyforge. The issue is to do with kerning data being stripped from one of the fonts and not the other, an easy fix. Windows is far more aggressive than other platforms in manipulating and modifying typefaces in it's attempts to mathematically optimise them for display on computer screens. Most times this backfires, but like I said, it's fixed now, I just don't have the ability to push the update. Meanwhile: Working on moving the whole thing over to being backed by the GitHub wiki, making it much more dynamic, and giving you all the opportunity to contribute to making the camping site great, without having to figure out webby and the rest. The wiki mirroring version is working really well locally. — Jenna___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Wiki Writing Requests!
Heya! So I'm trying to get this new website all tied up in a nice little bunch. I'm a bit silly when it comes to git-fu though. Could one of you create a page on the camping/camping wiki called 'Contributing', and put stuff in it which tells people how to do that? Use Markdown or Textile. Doesn't really matter which. I'm moving most of the articles I work on over to Markdown because textile and my brain don't like each other and I don't much like being stuck in the middle of their squabbles. Do whatever though. Thanks a bunch. — Pony ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Need input on proposed tweaks to www.ruby-camping.com
Okay. My web design is ready for prime time! You can see it up now at http://whitebook.mooo.com/ and http://campingrb.tumblr.com/ - keep in mind it's running off a home computer (called whitebook), so please don't send much traffic towards it. I've forked whywentcamping.com from the camping user on Github, and all these changes are up there. All you need to do is pull that, change the own_domain variable in layouts/default.txt to whatever, webby built in the CLI, and push it out to a server someplace. Oh, and let me know where it is so I can update the tumblog and if anyone wants in on the log, poke me an email address and I'll invite. Think community blog. I'll add the thingy to let people submit posts for consideration laters. Whatcha think? I'd like to make the headings look more interesting. Not sure how yet. Will experiment some. Also, need to rewrite homepage to be niftier, I think. — Jenna On 13/08/2010, at 8:19 PM, Dave Everitt wrote: Okay - we might be all running before we can walk, what with no real improvement to existing content yet. Everything I do professionally in this field starts with a solid content plan/list and a kind of strategy - there are some pretty good content suggestions in older posts. Before go any further (since we're all pretty busy) perhaps the main effort after all should go into refining the content on: http://whywentcamping.judofyr.net and avoiding duplication from: http://camping.rubyforge.org The only thing stopping me is that I have to get to grips with Webby, which I've never used. I was going down the Nanoc and Sass route before I got abducted by some nasty paid work. Or even make it all in... Camping (gasp!). But I do like the diversity of views of this group, although the healthy disagreement makes things hard to pin down. BTW Tumblr is fine (I use it), but why not use the blog on whywentcamping.judofyr.net instead? - DaveE My suggestion is that it not exist. Magnus already made a brilliant camping website at http://whywentcamping.judofyr.net/ It has content, but no drawings of tents. However I think we can have both in the same website. Could make an issue about it on the github issue tracker if you like. ___ 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: Need input on proposed tweaks to www.ruby-camping.com
I've yet to hear any compelling reason why that should be a separate 'site' on it's own domain name, over and away from everything else, rather than just a refresh of the existing camping homepage. You make some good points. We could write the homepage better. It's very dry at the moment. I'm very much against the wilful keeping of any sort of traffic statistics. Camping is a vibrant creative experimental project which often tries new hacks and ideas because we all feel free to do whatever. We're all just here having fun. Anyone who comes to camping wanting a serious framework will be disappointed. That's not to say you can't do serious things with camping, just that it's not what camping is about. The trouble with statistics is when you start paying attention to them, you can't help but change your behaviour to make the numbers do a little dance, and then it stops being a fun creative experimental place, and starts being a game where we try and 'win'. I don't want to play that game. I don't think many people here do. It's part of what makes this bunch special. Now there's nothing wrong with having a nicer homepage, and an all around more together website. We just need to remember what our goals are, collectively. We aren't a business. We have no motivation to see more users using camping, aside from a casual humanitarian effort. No marketing. Marketing is for people who need markets. We aren't in any of those. Not selling, camping. A silly little thing for making toys. Don't forget that. On 13/08/2010, at 11:42 PM, Philippe Monnet wrote: One thing is clear: we all love Camping! Months ago after seeing other frameworks like Sinatra and Padrino garner so much attention, I realized that the one thing missing on our side was not content but a marketing-oriented site to incite other rubyists to check out and try camping. So I drafted http://www.ruby-camping.com (after many posts on this mailing list) to serve as that marketing site to: 1. Quickly communicate what Camping is about 2. Advertise its strength and benefits 3. Provide links for people to download it, join the community and dive into the docs 4. Start tracking traffic so we can get a sense of whether or not we are starting to get some attention This is a very different goal from (and not mutually exclusive with) the goal of a blog or wiki. I also asked for help - knowing that we're all super busy. So I am glad some of you are starting to help out . On 8/13/2010 4:19 AM, Dave Everitt wrote: Okay - we might be all running before we can walk, what with no real improvement to existing content yet. Everything I do professionally in this field starts with a solid content plan/list and a kind of strategy - there are some pretty good content suggestions in older posts. Before go any further (since we're all pretty busy) perhaps the main effort after all should go into refining the content on: http://whywentcamping.judofyr.net and avoiding duplication from: http://camping.rubyforge.org The only thing stopping me is that I have to get to grips with Webby, which I've never used. I was going down the Nanoc and Sass route before I got abducted by some nasty paid work. Or even make it all in... Camping (gasp!). But I do like the diversity of views of this group, although the healthy disagreement makes things hard to pin down. BTW Tumblr is fine (I use it), but why not use the blog on whywentcamping.judofyr.net instead? - DaveE My suggestion is that it not exist. Magnus already made a brilliant camping website at http://whywentcamping.judofyr.net/ It has content, but no drawings of tents. However I think we can have both in the same website. Could make an issue about it on the github issue tracker if you like. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list --- Original Message Subject: Re: Wiki vs homepage Date: Thu, 08 Jul 2010 20:20:04 -0600 From: Philippe Monnet r...@monnet-usa.com Reply-To: camping-list@rubyforge.org To: camping-list@rubyforge.org 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
Re: Camping on StackOverflow
Speaking of the mailing list: rubyforge sucks! Couldn't we have something nice, like librelist? Those hackety hack guys with their fancy mailing list put ours to shame. _why is still the admin contact of this list. :| On 26/07/2010, at 12:18 AM, Dave Everitt wrote: There aren't enough Camping questions on SO to cherry pick :-) but getting them to use the mailing list would be good, although we'd also want to answer directly on SO - Dave E. On 25 Jul 2010, at 14:11, Philippe Monnet wrote: I think we probably need to also keep an eye on StackOverflow since it is now one of the top tech destinations with a super high amount of developer traffic. I just subscribed to the Camping tag RSS feed too. Also when answering we can encourage people to join our mailing list in our comments. I will check more often as I use StackOverflow several times a week anyway. I guess it's all part of our diversification to get the word out on Camping. Do you guys think we should cherry pick interesting questions every so often and either cross post to our list or maybe add to an FAQ page? On 7/25/2010 6:00 AM, Magnus Holm wrote: I've asked some of them (even though they are several months olds) and have also subscribed to the camping-tag. I'll try to automatically forward them to the 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
. 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-l...@rubyforge.orghttp://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
