Perhaps if this is working in time of the deployment screencast we can showcase
this kind of deployment AND unicorn/nginx!
--
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
david costa <gurugeek...@gmail.com> skrev:
BTW if you want to point a run.camping.io or 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> wrote:
oh sure ! for me is not a problem - love 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> wrote:
We can just use a *.camping.io catchall entry
On 31/03/2012, at 3:30 PM, david costa wrote:
Hello Jenna,
we could use host.camping.io or anything.camping.io for the frontend but if the
server has to allow users to create myfancyapp.camping.io it would be
complicated as I would need to run the 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> 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?
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 or ruby.am e.g. myfancyapp.camping.sh or myfancyapp.ruby.am
c) Database fanciness should also be available or at least sqlite/mysql
Suggestion and ideas on how to achieve this are welcome (or professionals with
the expertise willing to do a simple project based on this )
servers I can make available for this:
Debian 6
Intel Core i7 3930K (6 x 3,20 GHz)
RAM 64 GB
3000 GB HD + 256 MB SSD drive (very useful for databases, much faster)
OR (don't laugh)
Mac mini
2.0GHz quad-core Intel Core i7
8GB memory
2X256GB Solid State Drive
of course we would need to limit this to screened applicants to avoid any
spammers/troublemakers
Best Regards
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
_______________________________________________
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
Get the best selection of web sites here. Click Here to check them out!
http://click.lavabit.com/qszoentdu6cfiot97ef4mghqkwt1fg67m1hts7zqac5c8hghizob/
_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
