From aschneiderman at gmail.com  Thu Aug 25 09:25:27 2011
From: aschneiderman at gmail.com (Anders Schneiderman)
Date: Thu, 25 Aug 2011 09:25:27 -0400
Subject: Advice on strategy for maintaining state in Camping
Message-ID: <CAFi9PXLa_4fTQn-YiT6e1-dNTp9J60=zSeQDWsauSkzqpKOKMg@mail.gmail.com>

Hi,



I need a little advice about maintaining state in Camping.



I use NaturallySpeaking voice recognition software for most of my work -- I
don't have happy hands -- and I've been creating little Ruby projects to
make it easier to do some things by voice. I'd like to build a UI for them.
After some painful experiences with some windows-based UIs, I'd like to try
using Camping ? it looks like fun, and I can use my HTML/CSS skills to make
something pretty.



For most of these little Ruby projects, I don't have to store anything in a
database because the data is already being stored elsewhere. For example,
I'm managing a team that's building a Microsoft-based data warehouse that
uses Excel pivot tables as a front-end, and pivot tables are hard to
manipulate using NaturallySpeaking. On my Camping site, I want to be able to
display a long list of the available pivot table fields so I can click on
them by voice.  I also want a text box so I can say, e.g., "show department
and unit by row, year by column" or "only show fields containing committee."
So all I need to store is the info I'm using to manipulate the pivot table:
 the connection to the Excel worksheet and a list of the available fields
that I grab from the Excel worksheet plus one or two properties about these
fields. I don't need to save any of this info -- I grab it once at the
beginning of the session, and I don't want to cache it because, for example,
the list of fields will change depending on which data warehouse "cube" I'm
connecting to.  I have other projects where the data is stored on a
website/application that I'm grabbing/manipulating using Web services/APIs.
In short, I don't need to permanently store any data, I just need to
maintain state for a relatively small number of objects.



What's the easiest way to do this in Camping? Is there a way to cache the
list of field objects? Or does it make more sense to store them in a
database and purge & refresh the data in the database each time I start up
the Camping site?



Thanks!

Anders



PS Maybe you're thinking, "using Excel pivot tables as a front-end to a data
warehouse??" It does sound bizarre, and I was pretty skeptical at first, but
it actually works pretty well. Microsoft has put a fair amount of work into
turning Excel pivot tables into a pretty decent data warehouse front end.
And since you're just using Excel, you get all the goodies are built into
Excel. Not a good front-end if you are creating straightforward dashboards
that are totally locked down, but if you have a pretty broad range of fields
and you're encouraging folks to slice and dice the data themselves, it ends
up being easier than most of the other tools out there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110825/dc0e5a1c/attachment.html>

From judofyr at gmail.com  Thu Aug 25 11:27:29 2011
From: judofyr at gmail.com (Magnus Holm)
Date: Thu, 25 Aug 2011 17:27:29 +0200
Subject: Advice on strategy for maintaining state in Camping
In-Reply-To: <CAFi9PXLa_4fTQn-YiT6e1-dNTp9J60=zSeQDWsauSkzqpKOKMg@mail.gmail.com>
References: <CAFi9PXLa_4fTQn-YiT6e1-dNTp9J60=zSeQDWsauSkzqpKOKMg@mail.gmail.com>
Message-ID: <CAJ367fcyd8V5anNCHqGj4OE6+q9naO4Qr_hQ5j8Mua9Fp=ypNw@mail.gmail.com>

On Thu, Aug 25, 2011 at 15:25, Anders Schneiderman
<aschneiderman at gmail.com> wrote:
> Hi,
>
> I need a little advice about maintaining state in Camping.
>

Uh oh. Maintaining complex state is *always* a hassle, regardless of
language and framework?

The general way of maintaing state is using session cookies. It works like this:

  require 'camping'
  require 'camping/session'

  Camping.goes :App

  module App
    include Camping::Session
  end

  module App::Controllers
    class Index
      def get
        @state.counter = 0
        mab do
          p "Session ID = #{@state.session_id}"
          p 'Counter = 0'
          a 'Increment', :href => R(Increment)
        end
      end
    end

    class Increment
      def get
        @state.counter += 1
        "Counter: #{@state.counter}"
      end
    end
  end

Notes:
- See also http://camping.rubyforge.org/api.html#class-Camping-Session
- Note that you can't store more than ~3kB in sessions, so you shouldn't put
- `@state.session_id` is only available in Rack 1.3 (in previous
versions you have to generate it yourself if you need it)
- However, the current Camping release doesn't work well with Rack 1.3
when it comes to session
- That's fixed in the latest development version

I'm probably going to release a new version today or tomorrow. If you
can't wait until then, just run this command:

  gem install camping --source http://bob.judofyr.net/gem

> I use NaturallySpeaking voice recognition software for most of my work -- I
> don't have happy hands -- and I've been creating little Ruby projects to
> make it easier to do some things by voice. I'd like to build a UI for them.
> After some painful experiences with some windows-based UIs, I'd like to try
> using Camping ? it looks like fun, and I can use my HTML/CSS skills to make
> something pretty.

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)?

> For most of these little Ruby projects, I don't have to store anything in a
> database because the data is already being stored elsewhere. For example,
> I'm managing a team that's building a Microsoft-based data warehouse that
> uses?Excel pivot tables as a front-end, and pivot tables are hard to
> manipulate using NaturallySpeaking. On my Camping site, I want to be able to
> display a long list of the available pivot table fields so I can click on
> them by voice.? I also want a text box so I can say, e.g., "show department
> and unit by row, year by column" or "only show fields containing committee."
> So all I need to store is the info I'm using to manipulate the pivot table:
> ?the connection to the Excel worksheet and a list of the available fields
> that I grab from the Excel worksheet plus one or two properties about these
> fields. I don't need to save any of this info -- I grab it once at the
> beginning of the session, and I don't want to cache it because, for example,
> the list of fields will change depending on which data warehouse "cube" I'm
> connecting to.? I have other projects where the data is stored on a
> website/application that I'm grabbing/manipulating using Web services/APIs.
> In short, I don't need to permanently store any data, I just need to
> maintain state for a relatively small number of objects.
>
> What's the easiest way to do this in Camping? Is there a way to cache the
> list of field objects? Or does it make more sense to store them in a
> database and purge & refresh the data in the database each time I start up
> the Camping site?

I think you're going to save yourself a lot of problems if you can
download as much data and store it in a local database. It's much
faster and easier to just have everything in the database. Then you
can easily query it for whatever you need. See
http://whywentcamping.com/Book:-Getting-Started#Modeling-the-world for
how to use ActiveRecord to set up the database/schema.

You can either download the data in a controller (e.g. when someone
hits the front page) or just at startup. If only you're going to use
the app, it's probably easiest to load it at startup. If you want to
load it at startup, you should probably use a SQLite memory database.
This keeps all the database in memory and you don't have to clear it
everytime you start/stop your app.

Simply define a .create method (which the Camping server will call
when it starts up):

  def App.create
    App::Models::Base.establish_connection(:adapter => 'sqlite3',
:database => ':memory:')
  end

> Thanks!
>
> Anders

Hopefully this should get you somewhat started.

>
> PS Maybe you're thinking, "using Excel pivot tables as a front-end to a data
> warehouse??" It does sound bizarre, and I was pretty skeptical at first, but
> it actually works pretty well. Microsoft has put a fair amount of work into
> turning Excel pivot tables into a pretty decent data warehouse front end.
> And since you're just using Excel, you get all the goodies are built into
> Excel. Not a good front-end if you are creating straightforward dashboards
> that are totally locked down, but if you have a pretty broad range of fields
> and you're encouraging folks to slice and dice the data themselves, it ends
> up being easier than most of the other tools out there.

I'll have to admit that was exactly what I thought? But all that
really matters is that it works :-)

From dsusco at gmail.com  Thu Aug 25 11:28:48 2011
From: dsusco at gmail.com (David Susco)
Date: Thu, 25 Aug 2011 11:28:48 -0400
Subject: Advice on strategy for maintaining state in Camping
In-Reply-To: <CAFi9PXLa_4fTQn-YiT6e1-dNTp9J60=zSeQDWsauSkzqpKOKMg@mail.gmail.com>
References: <CAFi9PXLa_4fTQn-YiT6e1-dNTp9J60=zSeQDWsauSkzqpKOKMg@mail.gmail.com>
Message-ID: <CAC2piVdixCbwidxajW_GNsgitfKRaQePfP4HhsXgBqkvTrpjtg@mail.gmail.com>

If I'm understanding your question correctly I think judicious use of
the @state instance variable will achieve what you're looking for.
You'll be able to store what you need and be able to access it from
request to request.

Another option would be to use sqlite in memory mode.

App::Models::Base.establish_connection(:adapter=>'sqlite3',
:database=>':memory:')

You'll gain the benefits of a database but you'll be working in memory
only, so nothing's stored when your app is off.

Dave

On Thu, Aug 25, 2011 at 9:25 AM, Anders Schneiderman
<aschneiderman at gmail.com> wrote:
> Hi,
>
>
>
> I need a little advice about maintaining state in Camping.
>
>
>
> I use NaturallySpeaking voice recognition software for most of my work -- I
> don't have happy hands -- and I've been creating little Ruby projects to
> make it easier to do some things by voice. I'd like to build a UI for them.
> After some painful experiences with some windows-based UIs, I'd like to try
> using Camping ? it looks like fun, and I can use my HTML/CSS skills to make
> something pretty.
>
>
>
> For most of these little Ruby projects, I don't have to store anything in a
> database because the data is already being stored elsewhere. For example,
> I'm managing a team that's building a Microsoft-based data warehouse that
> uses?Excel pivot tables as a front-end, and pivot tables are hard to
> manipulate using NaturallySpeaking. On my Camping site, I want to be able to
> display a long list of the available pivot table fields so I can click on
> them by voice.? I also want a text box so I can say, e.g., "show department
> and unit by row, year by column" or "only show fields containing committee."
> So all I need to store is the info I'm using to manipulate the pivot table:
> ?the connection to the Excel worksheet and a list of the available fields
> that I grab from the Excel worksheet plus one or two properties about these
> fields. I don't need to save any of this info -- I grab it once at the
> beginning of the session, and I don't want to cache it because, for example,
> the list of fields will change depending on which data warehouse "cube" I'm
> connecting to.? I have other projects where the data is stored on a
> website/application that I'm grabbing/manipulating using Web services/APIs.
> In short, I don't need to permanently store any data, I just need to
> maintain state for a relatively small number of objects.
>
>
>
> What's the easiest way to do this in Camping? Is there a way to cache the
> list of field objects? Or does it make more sense to store them in a
> database and purge & refresh the data in the database each time I start up
> the Camping site?
>
>
>
> Thanks!
>
> Anders
>
>
>
> PS Maybe you're thinking, "using Excel pivot tables as a front-end to a data
> warehouse??" It does sound bizarre, and I was pretty skeptical at first, but
> it actually works pretty well. Microsoft has put a fair amount of work into
> turning Excel pivot tables into a pretty decent data warehouse front end.
> And since you're just using Excel, you get all the goodies are built into
> Excel. Not a good front-end if you are creating straightforward dashboards
> that are totally locked down, but if you have a pretty broad range of fields
> and you're encouraging folks to slice and dice the data themselves, it ends
> up being easier than most of the other tools out there.
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Dave

From judofyr at gmail.com  Thu Aug 25 13:20:24 2011
From: judofyr at gmail.com (Magnus Holm)
Date: Thu, 25 Aug 2011 19:20:24 +0200
Subject: Feature: Simple controllers?
Message-ID: <CAJ367fep=7Q9VC0qXvriASdUCOYKcZOAFJYBLpR2ua=H5VX68w@mail.gmail.com>

I just pushed a new feature to Camping: Simple controllers.

  module App::Controllers
    get '/(.*)' do |name|
      "Hello #{name}"
    end
  end

What do you think? Useful? Or should I revert it? It currently costs
us 87 bytes.

// Magnus Holm

From judofyr at gmail.com  Thu Aug 25 14:04:44 2011
From: judofyr at gmail.com (Magnus Holm)
Date: Thu, 25 Aug 2011 20:04:44 +0200
Subject: Feature: Inline templates?
Message-ID: <CAJ367feAa3PBQSnmmh5Yvph7fmRbajFp9FPZv+gz=0NUWeJ4eQ@mail.gmail.com>

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

From matma.rex at gmail.com  Thu Aug 25 14:31:35 2011
From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=)
Date: Thu, 25 Aug 2011 20:31:35 +0200
Subject: Feature: Simple controllers?
In-Reply-To: <CAJ367fep=7Q9VC0qXvriASdUCOYKcZOAFJYBLpR2ua=H5VX68w@mail.gmail.com>
References: <CAJ367fep=7Q9VC0qXvriASdUCOYKcZOAFJYBLpR2ua=H5VX68w@mail.gmail.com>
Message-ID: <CAA-yUx2diR7VCCRvfGv+fAwbFauwjSZRRaOVvQqv9_-GT-RmKQ@mail.gmail.com>

Personally I probably won't be using it, I like having class names
around and being able to link to them with R(). (I change my paths
often.) Certainly won't hurt to have it, for really small apps.

-- Matma Rex

From dsusco at gmail.com  Thu Aug 25 15:28:17 2011
From: dsusco at gmail.com (David Susco)
Date: Thu, 25 Aug 2011 15:28:17 -0400
Subject: Feature: Simple controllers?
In-Reply-To: <CAJ367fep=7Q9VC0qXvriASdUCOYKcZOAFJYBLpR2ua=H5VX68w@mail.gmail.com>
References: <CAJ367fep=7Q9VC0qXvriASdUCOYKcZOAFJYBLpR2ua=H5VX68w@mail.gmail.com>
Message-ID: <CAC2piVeNvKkLKjDWtafFqsGL2vFcwwy3FAR9U-wAJA+rsbpiVA@mail.gmail.com>

Would you have to write the RE for every declaration?

ie...

 module App::Controllers
   get '/(.*)' do |name|
     "Hello #{name}"
   end

   put '/(.*)' do |name|
     "Hello #{name}"
   end
 end

Dave

On Thu, Aug 25, 2011 at 1:20 PM, Magnus Holm <judofyr at gmail.com> wrote:
> I just pushed a new feature to Camping: Simple controllers.
>
> ?module App::Controllers
> ? ?get '/(.*)' do |name|
> ? ? ?"Hello #{name}"
> ? ?end
> ?end
>
> What do you think? Useful? Or should I revert it? It currently costs
> us 87 bytes.
>
> // Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Dave

From judofyr at gmail.com  Thu Aug 25 16:26:12 2011
From: judofyr at gmail.com (Magnus Holm)
Date: Thu, 25 Aug 2011 22:26:12 +0200
Subject: Feature: Simple controllers?
In-Reply-To: <CAC2piVeNvKkLKjDWtafFqsGL2vFcwwy3FAR9U-wAJA+rsbpiVA@mail.gmail.com>
References: <CAJ367fep=7Q9VC0qXvriASdUCOYKcZOAFJYBLpR2ua=H5VX68w@mail.gmail.com>
	<CAC2piVeNvKkLKjDWtafFqsGL2vFcwwy3FAR9U-wAJA+rsbpiVA@mail.gmail.com>
Message-ID: <CAJ367ff+Q2aZNzDfgSSNLfRSV1X494QVtkwm3MKQA8VVZYN+Tg@mail.gmail.com>

On Thu, Aug 25, 2011 at 21:28, David Susco <dsusco at gmail.com> wrote:
> Would you have to write the RE for every declaration?
>
> ie...
>
> ?module App::Controllers
> ? get '/(.*)' do |name|
> ? ? "Hello #{name}"
> ? end
>
> ? put '/(.*)' do |name|
> ? ? "Hello #{name}"
> ? end
> ?end

That wouldn't work. Camping would dispatch all methods to the first
controller (so you'll get a 501 error when you PUT).  In that case
you'll have to refactor it into a proper controller. Which I consider
a good thing (DRY etc.)

From john.beppu at gmail.com  Thu Aug 25 16:46:59 2011
From: john.beppu at gmail.com (John Beppu)
Date: Thu, 25 Aug 2011 13:46:59 -0700
Subject: Feature: Simple controllers?
In-Reply-To: <CAJ367fep=7Q9VC0qXvriASdUCOYKcZOAFJYBLpR2ua=H5VX68w@mail.gmail.com>
References: <CAJ367fep=7Q9VC0qXvriASdUCOYKcZOAFJYBLpR2ua=H5VX68w@mail.gmail.com>
Message-ID: <CA+N_sa1H6neav9eyyQ62Dm3Y0ZEJ530YzFn+z7VVP6jLaje6Yg@mail.gmail.com>

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.

On Thu, Aug 25, 2011 at 10:20 AM, Magnus Holm <judofyr at gmail.com> wrote:

> I just pushed a new feature to Camping: Simple controllers.
>
>  module App::Controllers
>    get '/(.*)' do |name|
>      "Hello #{name}"
>    end
>  end
>
> What do you think? Useful? Or should I revert it? It currently costs
> us 87 bytes.
>
> // Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110825/6be78627/attachment.html>

From judofyr at gmail.com  Thu Aug 25 17:21:13 2011
From: judofyr at gmail.com (Magnus Holm)
Date: Thu, 25 Aug 2011 23:21:13 +0200
Subject: Feature: Simple controllers?
In-Reply-To: <CA+N_sa1H6neav9eyyQ62Dm3Y0ZEJ530YzFn+z7VVP6jLaje6Yg@mail.gmail.com>
References: <CAJ367fep=7Q9VC0qXvriASdUCOYKcZOAFJYBLpR2ua=H5VX68w@mail.gmail.com>
	<CA+N_sa1H6neav9eyyQ62Dm3Y0ZEJ530YzFn+z7VVP6jLaje6Yg@mail.gmail.com>
Message-ID: <CAJ367ferK4V=WJ_r2mxmT-ZM6tW17v7nty+xnMrJwKZqPoJktA@mail.gmail.com>

On Aug 25, 2011 10:54 PM, "John Beppu" <john.beppu at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110825/905c593d/attachment.html>

From aschneiderman at gmail.com  Thu Aug 25 17:33:11 2011
From: aschneiderman at gmail.com (Anders Schneiderman)
Date: Thu, 25 Aug 2011 17:33:11 -0400
Subject: Advice on strategy for maintaining state in Camping
Message-ID: <CAFi9PX+RhMUuHSkX6ue0e+JXGZ6+tDrLmy-5JEVjHpwmKDoEPA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110825/50ccaa64/attachment.html>

From a at creativepony.com  Thu Aug 25 19:23:26 2011
From: a at creativepony.com (Jenna Fox)
Date: Fri, 26 Aug 2011 09:23:26 +1000
Subject: Feature: Simple controllers?
In-Reply-To: <CAJ367ferK4V=WJ_r2mxmT-ZM6tW17v7nty+xnMrJwKZqPoJktA@mail.gmail.com>
References: <CAJ367fep=7Q9VC0qXvriASdUCOYKcZOAFJYBLpR2ua=H5VX68w@mail.gmail.com>
	<CA+N_sa1H6neav9eyyQ62Dm3Y0ZEJ530YzFn+z7VVP6jLaje6Yg@mail.gmail.com>
	<CAJ367ferK4V=WJ_r2mxmT-ZM6tW17v7nty+xnMrJwKZqPoJktA@mail.gmail.com>
Message-ID: <808419D2-9713-4483-9919-A1D3D5D762DC@creativepony.com>

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.beppu at 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110826/e2c7972b/attachment.html>

From a at creativepony.com  Thu Aug 25 19:31:09 2011
From: a at creativepony.com (Jenna Fox)
Date: Fri, 26 Aug 2011 09:31:09 +1000
Subject: Advice on strategy for maintaining state in Camping
In-Reply-To: <CAFi9PX+RhMUuHSkX6ue0e+JXGZ6+tDrLmy-5JEVjHpwmKDoEPA@mail.gmail.com>
References: <CAFi9PX+RhMUuHSkX6ue0e+JXGZ6+tDrLmy-5JEVjHpwmKDoEPA@mail.gmail.com>
Message-ID: <7B60BC60-75C8-422E-8FAC-89416DF9E6F3@creativepony.com>

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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110826/b9dbaf42/attachment.html>

From john.beppu at gmail.com  Thu Aug 25 22:42:53 2011
From: john.beppu at gmail.com (John Beppu)
Date: Thu, 25 Aug 2011 19:42:53 -0700
Subject: Feature: Simple controllers?
In-Reply-To: <CAJ367ferK4V=WJ_r2mxmT-ZM6tW17v7nty+xnMrJwKZqPoJktA@mail.gmail.com>
References: <CAJ367fep=7Q9VC0qXvriASdUCOYKcZOAFJYBLpR2ua=H5VX68w@mail.gmail.com>
	<CA+N_sa1H6neav9eyyQ62Dm3Y0ZEJ530YzFn+z7VVP6jLaje6Yg@mail.gmail.com>
	<CAJ367ferK4V=WJ_r2mxmT-ZM6tW17v7nty+xnMrJwKZqPoJktA@mail.gmail.com>
Message-ID: <CA+N_sa0iAFHQ0JJPQhZ+x1AWvvkWX4jAtmDKRk+xZHXZ7MjnCg@mail.gmail.com>

Being able to name controllers definitely makes it more valuable.  If I had
to criticize Sinatra and its clones, I would criticize their lack of named
controllers.  It's difficult to write URL generation functions without them.
 I've only seen one Sinatra clone (Slim in php) that allows controllers to
be named.

On Thu, Aug 25, 2011 at 2:21 PM, Magnus Holm <judofyr at gmail.com> wrote:

> On Aug 25, 2011 10:54 PM, "John Beppu" <john.beppu at 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110825/bba2d12f/attachment-0001.html>

From _ at whats-your.name  Thu Aug 25 23:05:11 2011
From: _ at whats-your.name (cdr)
Date: Thu, 25 Aug 2011 20:05:11 -0700
Subject: Advice on strategy for maintaining state in Camping
In-Reply-To: <CAFi9PX+RhMUuHSkX6ue0e+JXGZ6+tDrLmy-5JEVjHpwmKDoEPA@mail.gmail.com>
References: <CAFi9PX+RhMUuHSkX6ue0e+JXGZ6+tDrLmy-5JEVjHpwmKDoEPA@mail.gmail.com>
Message-ID: <20110826030451.GA27767@myhost.clearwire-wmx.net>

> a SQLlight database seems like the best way to go

given your initial scenario of read-only Excel files, i disagree. why plumb data from Excel into SQLite and from SQLite into a web UI via several layers of Ruby code, themselves distanced from underlying datastores via ORM libraries, when you can specialized .XLS oriented tools oriented to non-coder (or quasi-coder)

i dont have anything to do with Cambridge Semantics, but if i had a copy of Excel or Windows i'd check it..

http://www.cambridgesemantics.com/products/anzo_for_excel

if massaging the data or filtering it one could try Refine:

https://code.google.com/p/google-refine/

if it was me, i usually use xls2txt and an on-the-fly RDF (to JSON/Hash in RAM) conversion and skip the SQL or "non-programmer" tools which mean well but never do quite what you want (or require excessive gymnastics vs a few lines of Ruby/Haskell)

http://gitorious.org/element/element/blobs/master/ruby/W/csv.rb

also Camping may be *just* what you are looking for..

From deveritt at innotts.co.uk  Fri Aug 26 10:14:43 2011
From: deveritt at innotts.co.uk (Dave Everitt)
Date: Fri, 26 Aug 2011 15:14:43 +0100
Subject: Feature: Inline templates?
In-Reply-To: <CAJ367feAa3PBQSnmmh5Yvph7fmRbajFp9FPZv+gz=0NUWeJ4eQ@mail.gmail.com>
References: <CAJ367feAa3PBQSnmmh5Yvph7fmRbajFp9FPZv+gz=0NUWeJ4eQ@mail.gmail.com>
Message-ID: <3C88508E-3824-4841-B5C2-AA7051F8FA0B@innotts.co.uk>

Since no-one has replied, for what it's worth (as a very amateur  
camper), I've always been happy with simple regular Markaby views and  
the v2.1 options for external templates. Also, my modest one-file  
apps have their CSS after __END__. In any sizeable app, you'd  
probably want to have separate templates for easier maintenance  
(since - if inline - their code is going to add more than a few lines  
and break the one-file advantages), so the question is: will anyone  
use/want inline templates? - DaveE

> On 25 Aug 2011, at 19:04, Magnus Holm wrote:
>
>>
> 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


From john.beppu at gmail.com  Fri Aug 26 11:54:00 2011
From: john.beppu at gmail.com (John Beppu)
Date: Fri, 26 Aug 2011 08:54:00 -0700
Subject: Feature: Inline templates?
In-Reply-To: <CAJ367feAa3PBQSnmmh5Yvph7fmRbajFp9FPZv+gz=0NUWeJ4eQ@mail.gmail.com>
References: <CAJ367feAa3PBQSnmmh5Yvph7fmRbajFp9FPZv+gz=0NUWeJ4eQ@mail.gmail.com>
Message-ID: <CA+N_sa37rwwrNCzsTLfy5j3uMbveNALnJKEhJXFKNa3qZHau7g@mail.gmail.com>

I was fine with Markaby.

On Thu, Aug 25, 2011 at 11:04 AM, Magnus Holm <judofyr at gmail.com> wrote:

> 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110826/922d5375/attachment.html>

From matma.rex at gmail.com  Fri Aug 26 12:16:21 2011
From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=)
Date: Fri, 26 Aug 2011 18:16:21 +0200
Subject: Feature: Inline templates?
In-Reply-To: <3C88508E-3824-4841-B5C2-AA7051F8FA0B@innotts.co.uk>
References: <CAJ367feAa3PBQSnmmh5Yvph7fmRbajFp9FPZv+gz=0NUWeJ4eQ@mail.gmail.com>
	<3C88508E-3824-4841-B5C2-AA7051F8FA0B@innotts.co.uk>
Message-ID: <CAA-yUx0y7y7cSOT48hs2b-6zKSdj6DjaG_9RJA7PkaJdx_BSig@mail.gmail.com>

If this only supports Erb, then we should throw it away as fast as
possible ;) I see no reason why would anyone want to use something
*that* dinosauric in a new project.

If it also supports (or can support), say, Haml, then I see how it
could be useful (although nearly all of my Camping projects end up
split between many files anyway ;) ). Personally I love Markaby, but
for many people it might look weird, and I can understand why.

-- Matma Rex

From judofyr at gmail.com  Fri Aug 26 12:58:04 2011
From: judofyr at gmail.com (Magnus Holm)
Date: Fri, 26 Aug 2011 18:58:04 +0200
Subject: Feature: Inline templates?
In-Reply-To: <CAA-yUx0y7y7cSOT48hs2b-6zKSdj6DjaG_9RJA7PkaJdx_BSig@mail.gmail.com>
References: <CAJ367feAa3PBQSnmmh5Yvph7fmRbajFp9FPZv+gz=0NUWeJ4eQ@mail.gmail.com>
	<3C88508E-3824-4841-B5C2-AA7051F8FA0B@innotts.co.uk>
	<CAA-yUx0y7y7cSOT48hs2b-6zKSdj6DjaG_9RJA7PkaJdx_BSig@mail.gmail.com>
Message-ID: <CAJ367fdxNz+a1DnyG3MpUhaNToiokfSsX3w06HoHDZfMmpPWfQ@mail.gmail.com>

On Aug 26, 2011 6:42 PM, "Bartosz Dziewo?ski" <matma.rex at gmail.com> wrote:
>
> If this only supports Erb, then we should throw it away as fast as
> possible ;) I see no reason why would anyone want to use something
> *that* dinosauric in a new project.
>
> If it also supports (or can support), say, Haml, then I see how it
> could be useful (although nearly all of my Camping projects end up
> split between many files anyway ;) ). Personally I love Markaby, but
> for many people it might look weird, and I can understand why.
>
> -- Matma Rex

It supports everything that Tilt supports. See
http://github.com/rtomayko/tilt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110826/40093298/attachment.html>

From ruby at monnet-usa.com  Sat Aug 27 10:13:58 2011
From: ruby at monnet-usa.com (Philippe Monnet)
Date: Sat, 27 Aug 2011 08:13:58 -0600
Subject: Feature: Inline templates?
In-Reply-To: <CAJ367fdxNz+a1DnyG3MpUhaNToiokfSsX3w06HoHDZfMmpPWfQ@mail.gmail.com>
References: <CAJ367feAa3PBQSnmmh5Yvph7fmRbajFp9FPZv+gz=0NUWeJ4eQ@mail.gmail.com>
	<3C88508E-3824-4841-B5C2-AA7051F8FA0B@innotts.co.uk>
	<CAA-yUx0y7y7cSOT48hs2b-6zKSdj6DjaG_9RJA7PkaJdx_BSig@mail.gmail.com>
	<CAJ367fdxNz+a1DnyG3MpUhaNToiokfSsX3w06HoHDZfMmpPWfQ@mail.gmail.com>
Message-ID: <4E58FBA6.2070706@monnet-usa.com>

I am a bit ambivalent about the new feature. One hand it's kind of cool. 
But on the other it's something that most experienced campers probably 
won't use on moderate size apps. And for new campers it's one more 
syntactic sugar to learn and remember.

On 8/26/2011 10:58 AM, Magnus Holm wrote:
>
> On Aug 26, 2011 6:42 PM, "Bartosz Dziewon'ski" <matma.rex at gmail.com 
> <mailto:matma.rex at gmail.com>> wrote:
> >
> > If this only supports Erb, then we should throw it away as fast as
> > possible ;) I see no reason why would anyone want to use something
> > *that* dinosauric in a new project.
> >
> > If it also supports (or can support), say, Haml, then I see how it
> > could be useful (although nearly all of my Camping projects end up
> > split between many files anyway ;) ). Personally I love Markaby, but
> > for many people it might look weird, and I can understand why.
> >
> > -- Matma Rex
>
> It supports everything that Tilt supports. See 
> http://github.com/rtomayko/tilt.
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110827/f3e6fe37/attachment.html>

From aschneiderman at gmail.com  Sat Aug 27 15:30:51 2011
From: aschneiderman at gmail.com (Anders Schneiderman)
Date: Sat, 27 Aug 2011 15:30:51 -0400
Subject: Advice on strategy for maintaining state in Camping
Message-ID: <4A7B0782-3DCB-4E73-8F95-12DCB546EB26@gmail.com>

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?

Thanks, Jenna!  Sounds good.

Since I'm new to camping, can you tell me where I would add the global objects?

Anders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110827/ab8a5442/attachment.html>

From a at creativepony.com  Sat Aug 27 19:27:29 2011
From: a at creativepony.com (Jenna Fox)
Date: Sun, 28 Aug 2011 09:27:29 +1000
Subject: Advice on strategy for maintaining state in Camping
In-Reply-To: <4A7B0782-3DCB-4E73-8F95-12DCB546EB26@gmail.com>
References: <4A7B0782-3DCB-4E73-8F95-12DCB546EB26@gmail.com>
Message-ID: <E7BC5291-44BD-45F6-B098-DE378DC94AB1@creativepony.com>

There are a few places you could stash one.

If you have some class somewhere, say, MyThinger, you could declare a little accessor like this:

class MyThinger
	class << self
		attr_accessor :things
	end
end

Then you would be able to write MyThinger.things and use it like a variable, getting and setting it to whatever stuff you'd like to keep around.

The other simpler way to do it would be to just use a Global Variable. In ruby, a global variable is any variable which begins with a $. So, you could use $things, and it'd stick around. It's usually considered bad practice to use them, but if you choose a descriptive name nothing else is likely to want to use, there really is no justification for such fears.


?
Jenna


On 28/08/2011, at 5:30 AM, Anders Schneiderman wrote:

> 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?
> 
> Thanks, Jenna!  Sounds good.
> 
> Since I'm new to camping, can you tell me where I would add the global objects?
> 
> Anders
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110828/0c31525e/attachment-0001.html>

From danbryan at gmail.com  Sat Aug 27 22:58:48 2011
From: danbryan at gmail.com (Daniel Bryan)
Date: Sun, 28 Aug 2011 12:58:48 +1000
Subject: Using CouchDB in Camping - looking for advice
Message-ID: <67B42A12D5C949CFAC2C43457B95EC41@gmail.com>

Hello camping people

I've written a Ruby library for working with CouchDB. It's a pretty thin API - it provides a database object, a document object (a glorified hash) and a design object. 

In case anyone's not familiar with CouchDB, it's a schema-less JSON document database with a HTTP interface. You store documents in the database, then query the database with MapReduce views. Your map and reduce queries are just JavaScript, and they're stored as fields of design documents. Generally, each design document corresponds to an 'app'.

So it's all lovely and simple, and I've been working on writing a module that plugs my API into Camping.

Models look like this:

> module MyFood::Models
>  class Recipe < CouchDocument
>  needs :name
>  needs :ingredients
>  needs :instructions
>  suggests :dates_cooked, :array
>  suggests :cost
>  end
> end




CouchDocument is a hash with some methods for pushing to and pulling from the document database, and some validation functions. "needs" and "suggests" both just refer to keys. I haven't decided exactly how to implement "suggests" yet; "needs" enforces the existence of particular keys before a document can be pushed. It also looks at the name of the class and uses it for a "kind" or "type" key.

I've written a small library that uses S Expressions to parse Ruby into JavaScript. It's limited, but for the moment it's adequate to my purposes: writing JavaScript MapReduce functions as Ruby blocks. This means you can do this:

> module MyFood::MapReduce
>  view :untried_recipes do
>  map do
>  emit(doc.name, doc) if doc.kind == "Recipe" and doc.dates_cooked.length == 0
>  end
>  end
> 
> 
>  view :cost_of_crazy_huge_indian_meal
>  map do
>  emit(doc.name, doc.cost) if doc.kind == "Recipe" and doc.cuisine == "South Asian"
>  end
>  reduce do
>  return sum(values)
>  end
>  end
> end

And you get a design document with two entries in the "views" field:

> "map"=> 
> "function ( doc ) { 
>  if( doc.kind == "Recipe" && doc.dates_cooked.length == 0 ) {
>  emit(doc.name, doc)
>  } 
> }"



And:

> "map" =>
> "function ( doc ) { 
>  if( doc.kind == "Recipe" && doc.cuisine == "South Asian" ) {
>  emit(doc.name, doc.cost)
>  } 
> }", "reduce"=>
> "function ( key, values, rereduce ) { 
>  return sum(values) 
> }"



So, yeah, whatever, that's all well and good, you can write your queries and it'll update the design document on the server so you can just do a HTTP GET request to the view's URL and CouchDB will return your rows or whatever. Cool. The thing is, I have no idea how to unify this with Camping. I feel like a "relaxing" schema-less thing like this is the perfect match for really small web projects, and there's the added bonus that since the CouchDB settings are just defined in a global variable at the top of your app, you can have different databases - or even different database servers - for different Camping apps running on the same web server if you like.

There's been a bit of discussion on the list lately about how great it is that Ruby's controllers belong to classes - there's an intrinsic logic to it. I want something as intuitive as that for this query language, but I don't know how to do it. The earliest implementation of this I did just had a Design class, and when you wrote a view it'd define a method on the Design class with that view's name - so, above, you'd call Design.untried_recipes, or Design.cost_of_blahblah, and it'd query Couch for the result. That's okay until you have more than a small handful of views - more than that, and there's too much to keep track of.

The views could just belong to models, so you could call Recipe.untried, or something, but the thing about MapReduce is that so many of your queries don't naturally belong to a particular "model", and I don't really want to built an architecture that makes people tend to write their models and queries as if it's SQL and you need to normalise and get all heavy with joins and generally ruin your life with boredom. If you want a view with particular data, you write a view that gives you exactly that, you save it, CouchDB automatically caches it in your fancy B-trees, and you're rolling. It's beautiful, but I don't know how to make it user-friendly.

So uh

does anyone

have any advice?

-- Cerales (@lodoicea)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110828/231c49df/attachment.html>

From judofyr at gmail.com  Sun Aug 28 11:54:51 2011
From: judofyr at gmail.com (Magnus Holm)
Date: Sun, 28 Aug 2011 17:54:51 +0200
Subject: Using CouchDB in Camping - looking for advice
In-Reply-To: <67B42A12D5C949CFAC2C43457B95EC41@gmail.com>
References: <67B42A12D5C949CFAC2C43457B95EC41@gmail.com>
Message-ID: <CAJ367fe5+CVE1vZa87behhcixZ+=WV0cUvUZmjXGFDTW50FnnQ@mail.gmail.com>

On Sun, Aug 28, 2011 at 04:58, Daniel Bryan <danbryan at gmail.com> wrote:

> Hello camping people
>
> I've written a Ruby library for working with CouchDB. It's a pretty thin
> API - it provides a database object, a document object (a glorified hash)
> and a design object.
>
> In case anyone's not familiar with CouchDB, it's a schema-less JSON
> document database with a HTTP interface. You store documents in the
> database, then query the database with MapReduce views. Your map and reduce
> queries are just JavaScript, and they're stored as fields of design
> documents. Generally, each design document corresponds to an 'app'.
>
> So it's all lovely and simple, and I've been working on writing a module
> that plugs my API into Camping.
>
> ?
>
> I've written a small library that uses S Expressions to parse Ruby into
> JavaScript. It's limited, but for the moment it's adequate to my purposes:
> writing JavaScript MapReduce functions as Ruby blocks. This means you can do
> this:
>
> module MyFood::MapReduce
>   view :untried_recipes do
>     map do
>         emit(doc.name, doc) if doc.kind == "Recipe" and
> doc.dates_cooked.length == 0
>     end
>   end
>
>   view :cost_of_crazy_huge_indian_meal
>     map do
>       emit(doc.name, doc.cost) if doc.kind == "Recipe" and doc.cuisine ==
> "South Asian"
>     end
>     reduce do
>       return sum(values)
>     end
>   end
> end
>
> And you get a design document with two entries in the "views" field:
>
> "map"=>
> "function ( doc ) {
>   if( doc.kind == "Recipe" && doc.dates_cooked.length == 0 ) {
>     emit(doc.name, doc)
>   }
> }"
>
>
> And:
>
> "map" =>
> "function ( doc ) {
>   if( doc.kind == "Recipe" && doc.cuisine == "South Asian" ) {
>     emit(doc.name, doc.cost)
>   }
> }", "reduce"=>
> "function ( key, values, rereduce ) {
>   return sum(values)
> }"
>
>
>
Woah, that sounds pretty cool. Are you using RubyParser or Ripper?

So, yeah, whatever, that's all well and good, you can write your queries and
> it'll update the design document on the server so you can just do a HTTP GET
> request to the view's URL and CouchDB will return your rows or whatever.
> Cool. The thing is, I have no idea how to unify this with Camping. I feel
> like a "relaxing" schema-less thing like this is the perfect match for
> really small web projects, and there's the added bonus that since the
> CouchDB settings are just defined in a global variable at the top of your
> app, you can have different databases - or even different database servers -
> for different Camping apps running on the same web server if you like.
>
> There's been a bit of discussion on the list lately about how great it is
> that Ruby's controllers belong to classes - there's an intrinsic logic to
> it. I want something as intuitive as that for this query language, but I
> don't know how to do it. The earliest implementation of this I did just had
> a Design class, and when you wrote a view it'd define a method on the Design
> class with that view's name - so, above, you'd call Design.untried_recipes,
> or Design.cost_of_blahblah, and it'd query Couch for the result. That's okay
> until you have more than a small handful of views - more than that, and
> there's too much to keep track of.
>

I agree. What's the point of namespaces (modules/classes) if you're going to
store everything in the same place?


> The views could just belong to models, so you could call Recipe.untried, or
> something, but the thing about MapReduce is that so many of your queries
> don't naturally belong to a particular "model", and I don't really want to
> built an architecture that makes people tend to write their models and
> queries as if it's SQL and you need to normalise and get all heavy with
> joins and generally ruin your life with boredom. If you want a view with
> particular data, you write a view that gives you exactly that, you save it,
> CouchDB automatically caches it in your fancy B-trees, and you're rolling.
> It's beautiful, but I don't know how to make it user-friendly.
>

I actually have the same problem with ActiveRecord: There's so many things
that's working across tables, but it forces you to put it in one model. I
don't think that even makes sense in a SQL-world. It doesn't make sense in a
relational world, but it seems people like objects so well that they try to
put the (quite sensible) relational model in a object-oriented world?


> So uh
>
> does anyone
>
> have any advice?
>
> -- Cerales (@lodoicea)
>

It's a hard problem that you've stumbled upon; trying to integrate two quite
different point-of-views (Ruby vs CouchDb) in an elegant way.

Okay, let's see? First of all: Does all MapReduce-queries work on different
types of documents; i.e. does it make sense to run MapReduce on just one
type of documents? I guess so? In that cases, it would be quite useful to
say `Receipes.tagged_with("Bacon")`?

What if you introduce the concept of *contexts*? So all CouchDocument are
automatically one context (that only include one type of document), but you
can also introduce your own contexts. So you can have a CookingUser-context,
which describes a User and what he can do with Receipes. In your controller
you can say `CookingUser.new(current_user).untried_recepies`. Or maybe a
UserReceipes which has an "untried"-view.

So contexts are just a lightweight class where you can place your views. The
developer has to decide what the context should be called and how they
should work. The point is that the contexts should mirror the use-cases of
the data, and as there might be many ways to look at the same data, you
can't have an automatic way of saying where the view belongs. It all depends
on the point-of-view.

I guess what I'm really trying to say: Don't have one class where you put
everything. Don't force the views to belong to one set of classes. Do
something in-between: Let the views live where they make sense, sometimes on
a CouchDocument-class (when the views only work on that class), sometimes on
a custom class (where it's the developer who decides what that class
*means*).

I'll have to admit that these are mainly my thoughts on the general "It
sucks to place all queries in only ActiveRecord-classes"-problem I mentioned
above, but I hope this might be applicable in other cases too?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110828/47778d95/attachment-0001.html>

From danbryan at gmail.com  Sun Aug 28 23:39:20 2011
From: danbryan at gmail.com (Daniel Bryan)
Date: Mon, 29 Aug 2011 13:39:20 +1000
Subject: Using CouchDB in Camping - looking for advice
In-Reply-To: <CAJ367fe5+CVE1vZa87behhcixZ+=WV0cUvUZmjXGFDTW50FnnQ@mail.gmail.com>
References: <67B42A12D5C949CFAC2C43457B95EC41@gmail.com>
	<CAJ367fe5+CVE1vZa87behhcixZ+=WV0cUvUZmjXGFDTW50FnnQ@mail.gmail.com>
Message-ID: <EE91F9D4729A4434AF255B577F4D0CFE@gmail.com>

> Woah, that sounds pretty cool. Are you using RubyParser or Ripper?
Neither. I'm using sourcify ( http://rubydoc.info/gems/sourcify/0.5.0/frames ) to convert blocks into an S Expression, and then my own library to parse that and spit out equivalent JavaScript syntax. I've made no attempt to deal with Ruby syntax that has no direct JS equivalent (like block arguments to function calls), nor to capture operations that would be illegal in JavaScript - https://github.com/cerales/ShyRubyJS

> Okay, let's see? First of all: Does all MapReduce-queries work on different types of documents; i.e. does it make sense to run MapReduce on just one type of documents? I guess so? In that cases, it would be quite useful to say `Receipes.tagged_with("Bacon")`?
Yeah, it does make sense, and a lot of the time you might want to do queries that just get a particular "kind" of document and filter it in some way. Regardless of the final solution I think that should be supported, so I guess I'll try to think of a robust query language for that kind of thing.

> What if you introduce the concept of *contexts*? So all CouchDocument are automatically one context (that only include one type of document), but you can also introduce your own contexts. So you can have a CookingUser-context, which describes a User and what he can do with Receipes. In your controller you can say `CookingUser.new(current_user).untried_recepies`. Or maybe a UserReceipes which has an "untried"-view.
>  
> So contexts are just a lightweight class where you can place your views. The developer has to decide what the context should be called and how they should work. The point is that the contexts should mirror the use-cases of the data, and as there might be many ways to look at the same data, you can't have an automatic way of saying where the view belongs. It all depends on the point-of-view.

I like this!

The way I'm interpreting this is that contexts could be a really light layer on top of the anonymous views. So it'd have your abstract view specification - a map block and a view block - and then a couple of little links specifying, for example, which model classes / "kinds" it's associated with, for the sake of the developer's sanity.

When I started development on this concept, I put a lot of thought into how models would be written, to the point that they became effectively a schema. I realised that that was absurd - anything heavier than the optional "needs" and "suggests" concepts is throwing away the agility, convenience and forgiveness of a NoSQL approach.

So that's out the window, but there's still a challenge here - model schemas, as well as being a concession to the brutality of SQL and its greedy demands, are a very useful tool for keeping track of and self-documenting your application. It seems there needs to be some kind of tool to replace that if your'e doing something like this.

So what I'm thinking might be useful is some kind of optional admin interface that will look at your Models and your Views and your Contexts, and try to visualise or contextualise them in some way. Like the django admin interface, with all the power of introspection, but somehow groovy.

Of course, it's so _easy_ to work with data when it's just JSON documents that there's no reason you couldn't, with a little thought, build a super user-friendly interface where you build your MapReduce views just by being given a graphical view of your document Kinds and dragging and dropping things into the fields for what you want to emit, what you want to filter, etc. It's probably not the best idea philosophically, but for giving people the tools to really easily write a dynamic web app it seems like it could be useful.

brain racing aaaaaaa

Thanks for the help, Judofyr

- Daniel / Cerales




On Monday, 29 August 2011 at 1:54 AM, Magnus Holm wrote:

> On Sun, Aug 28, 2011 at 04:58, Daniel Bryan <danbryan at gmail.com (mailto:danbryan at gmail.com)> wrote:
> > Hello camping people
> >  
> > I've written a Ruby library for working with CouchDB. It's a pretty thin API - it provides a database object, a document object (a glorified hash) and a design object.  
> >  
> > In case anyone's not familiar with CouchDB, it's a schema-less JSON document database with a HTTP interface. You store documents in the database, then query the database with MapReduce views. Your map and reduce queries are just JavaScript, and they're stored as fields of design documents. Generally, each design document corresponds to an 'app'.  
> >  
> > So it's all lovely and simple, and I've been working on writing a module that plugs my API into Camping.
> >  
> > ?
> >  
> > I've written a small library that uses S Expressions to parse Ruby into JavaScript. It's limited, but for the moment it's adequate to my purposes: writing JavaScript MapReduce functions as Ruby blocks. This means you can do this:  
> >  
> > > module MyFood::MapReduce
> > >  view :untried_recipes do
> > >  map do
> > >  emit(doc.name (http://doc.name), doc) if doc.kind == "Recipe" and doc.dates_cooked.length == 0
> > >  end
> > >  end
> > >  
> > >  
> > >  view :cost_of_crazy_huge_indian_meal
> > >  map do
> > >  emit(doc.name (http://doc.name), doc.cost) if doc.kind == "Recipe" and doc.cuisine == "South Asian"
> > >  end
> > >  reduce do
> > >  return sum(values)
> > >  end
> > >  end
> > > end
> > >  
> >  
> > And you get a design document with two entries in the "views" field:
> >  
> > > "map"=>  
> > > "function ( doc ) {  
> > >  if( doc.kind == "Recipe" && doc.dates_cooked.length == 0 ) {
> > >  emit(doc.name (http://doc.name), doc)
> > >  }  
> > > }"
> > >  
> >  
> >  
> > And:
> >  
> > > "map" =>
> > > "function ( doc ) {  
> > >  if( doc.kind == "Recipe" && doc.cuisine == "South Asian" ) {
> > >  emit(doc.name (http://doc.name), doc.cost)
> > >  }  
> > > }", "reduce"=>
> > > "function ( key, values, rereduce ) {  
> > >  return sum(values)  
> > > }"
> > >  
> >  
> >  
>  
> Woah, that sounds pretty cool. Are you using RubyParser or Ripper?
>  
> > So, yeah, whatever, that's all well and good, you can write your queries and it'll update the design document on the server so you can just do a HTTP GET request to the view's URL and CouchDB will return your rows or whatever. Cool. The thing is, I have no idea how to unify this with Camping. I feel like a "relaxing" schema-less thing like this is the perfect match for really small web projects, and there's the added bonus that since the CouchDB settings are just defined in a global variable at the top of your app, you can have different databases - or even different database servers - for different Camping apps running on the same web server if you like.  
> >  
> > There's been a bit of discussion on the list lately about how great it is that Ruby's controllers belong to classes - there's an intrinsic logic to it. I want something as intuitive as that for this query language, but I don't know how to do it. The earliest implementation of this I did just had a Design class, and when you wrote a view it'd define a method on the Design class with that view's name - so, above, you'd call Design.untried_recipes, or Design.cost_of_blahblah, and it'd query Couch for the result. That's okay until you have more than a small handful of views - more than that, and there's too much to keep track of.  
>  
> I agree. What's the point of namespaces (modules/classes) if you're going to store everything in the same place?
>  
> > The views could just belong to models, so you could call Recipe.untried, or something, but the thing about MapReduce is that so many of your queries don't naturally belong to a particular "model", and I don't really want to built an architecture that makes people tend to write their models and queries as if it's SQL and you need to normalise and get all heavy with joins and generally ruin your life with boredom. If you want a view with particular data, you write a view that gives you exactly that, you save it, CouchDB automatically caches it in your fancy B-trees, and you're rolling. It's beautiful, but I don't know how to make it user-friendly.  
> >  
>  
>  
> I actually have the same problem with ActiveRecord: There's so many things that's working across tables, but it forces you to put it in one model. I don't think that even makes sense in a SQL-world. It doesn't make sense in a relational world, but it seems people like objects so well that they try to put the (quite sensible) relational model in a object-oriented world?  
>  
> > So uh
> >  
> > does anyone
> >  
> > have any advice?  
> >  
> > -- Cerales (@lodoicea)
>  
> It's a hard problem that you've stumbled upon; trying to integrate two quite different point-of-views (Ruby vs CouchDb) in an elegant way.  
> Okay, let's see? First of all: Does all MapReduce-queries work on different types of documents; i.e. does it make sense to run MapReduce on just one type of documents? I guess so? In that cases, it would be quite useful to say `Receipes.tagged_with("Bacon")`?  
>  
> What if you introduce the concept of *contexts*? So all CouchDocument are automatically one context (that only include one type of document), but you can also introduce your own contexts. So you can have a CookingUser-context, which describes a User and what he can do with Receipes. In your controller you can say `CookingUser.new(current_user).untried_recepies`. Or maybe a UserReceipes which has an "untried"-view.  
>  
> So contexts are just a lightweight class where you can place your views. The developer has to decide what the context should be called and how they should work. The point is that the contexts should mirror the use-cases of the data, and as there might be many ways to look at the same data, you can't have an automatic way of saying where the view belongs. It all depends on the point-of-view.  
>  
> I guess what I'm really trying to say: Don't have one class where you put everything. Don't force the views to belong to one set of classes. Do something in-between: Let the views live where they make sense, sometimes on a CouchDocument-class (when the views only work on that class), sometimes on a custom class (where it's the developer who decides what that class *means*).  
>  
> I'll have to admit that these are mainly my thoughts on the general "It sucks to place all queries in only ActiveRecord-classes"-problem I mentioned above, but I hope this might be applicable in other cases too?  
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110829/836ae778/attachment.html>

From deveritt at innotts.co.uk  Mon Aug 29 07:40:18 2011
From: deveritt at innotts.co.uk (Dave Everitt)
Date: Mon, 29 Aug 2011 12:40:18 +0100
Subject: Using CouchDB in Camping - looking for advice
In-Reply-To: <EE91F9D4729A4434AF255B577F4D0CFE@gmail.com>
References: <67B42A12D5C949CFAC2C43457B95EC41@gmail.com>
	<CAJ367fe5+CVE1vZa87behhcixZ+=WV0cUvUZmjXGFDTW50FnnQ@mail.gmail.com>
	<EE91F9D4729A4434AF255B577F4D0CFE@gmail.com>
Message-ID: <C3354EA8-E8A0-4CEE-9F6F-7B08396E5DD1@innotts.co.uk>

> So what I'm thinking might be useful is some kind of optional admin  
> interface that will look at your Models and your Views and your  
> Contexts, and try to visualise or contextualise them in some way.  
> Like the django admin interface, with all the power of  
> introspection, but somehow groovy.
>
> Of course, it's so _easy_ to work with data when it's just JSON  
> documents that there's no reason you couldn't, with a little  
> thought, build a super user-friendly interface where you build your  
> MapReduce views just by being given a graphical view of your  
> document Kinds and dragging and dropping things into the fields for  
> what you want to emit, what you want to filter, etc. It's probably  
> not the best idea philosophically, but for giving people the tools  
> to really easily write a dynamic web app it seems like it could be  
> useful.

I have to say that sounds *really* interesting - DaveE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110829/a9836c1a/attachment-0001.html>

From theonetruewaffles at gmail.com  Mon Aug 29 23:47:08 2011
From: theonetruewaffles at gmail.com (Anonymous Waffles)
Date: Mon, 29 Aug 2011 20:47:08 -0700
Subject: Help with Controllers
Message-ID: <CAO7L_L7B0dedqzh3jQELunV2nBwVGDSUg6XsyJ0wPJQUofV6Eg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110829/0036e722/attachment.html>

From a at creativepony.com  Tue Aug 30 00:27:43 2011
From: a at creativepony.com (Jenna Fox)
Date: Tue, 30 Aug 2011 14:27:43 +1000
Subject: Help with Controllers
In-Reply-To: <CAO7L_L7B0dedqzh3jQELunV2nBwVGDSUg6XsyJ0wPJQUofV6Eg@mail.gmail.com>
References: <CAO7L_L7B0dedqzh3jQELunV2nBwVGDSUg6XsyJ0wPJQUofV6Eg@mail.gmail.com>
Message-ID: <F19F660E-4585-434C-AC10-55F64C4CF3FC@creativepony.com>

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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110830/e3d86376/attachment.html>

From john.beppu at gmail.com  Tue Aug 30 00:57:42 2011
From: john.beppu at gmail.com (John Beppu)
Date: Mon, 29 Aug 2011 21:57:42 -0700
Subject: Help with Controllers
In-Reply-To: <CAO7L_L7B0dedqzh3jQELunV2nBwVGDSUg6XsyJ0wPJQUofV6Eg@mail.gmail.com>
References: <CAO7L_L7B0dedqzh3jQELunV2nBwVGDSUg6XsyJ0wPJQUofV6Eg@mail.gmail.com>
Message-ID: <CA+N_sa2=UddrCHKp1uzOw9vuOAPdR4k0q3B6Ay5-Fv6V0Nb43g@mail.gmail.com>

On Mon, Aug 29, 2011 at 8:47 PM, Anonymous Waffles <
theonetruewaffles at gmail.com> 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?*
>

No.  A form's action attribute requires a path or a URL.  Controllers are
not usually meaningful paths.  Therefore, you should continue to use the R()
function to generate paths.

An alternative to using the R() function would be to generate a path
yourself.

"/page/#{@page.title}"  <-- That would work, but I personally recommend
sticking to using the R() function.  It gives you the freedom to tweak the
URL structure of your web app with minimal pain.


And how is it sent along? Must the post method have a certain argument?
>

Let's pretend this is our PageX controller:

class PageX

  def get(title)
    @page = H.new
    @page.title = title
    render :page
  end

  def post(title)
    content = *@input.content*
    # do something with content and then...
    redirect R(PageX, title)
  end

end


When someone submits the form you made, the post() method of the PageX
controller will be run, and all the form variables will be in @input.

Hope that helps.

--beppu





PS:  A question for those who have deep Camping knowledge....  Since when
did Camping support "Simpler Routes" as described in
http://camping.rubyforge.org/book/02_getting_started.html ?

I had no idea until just a few minutes ago that capital "N" and "X" had a
special meaning in controller names.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110829/c64c3783/attachment.html>

From john.beppu at gmail.com  Tue Aug 30 01:09:42 2011
From: john.beppu at gmail.com (John Beppu)
Date: Mon, 29 Aug 2011 22:09:42 -0700
Subject: What is the Best Way to Install Camping in 2011?
Message-ID: <CA+N_sa11ahc0g2Ve5u6ZjkvRFP1BSXGLMQsELzh=VVGrw1=2qw@mail.gmail.com>

Let's say I have a pristine Unixy system in front of me.  (In my case, it's
a new OS X 10.7 installation and I put MacPorts on there.)

What is the simplest way to get an up-to-date Camping installation?

(I've been out of the Ruby loop for a while.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110829/56cb4b7e/attachment.html>

From matma.rex at gmail.com  Tue Aug 30 04:05:50 2011
From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=)
Date: Tue, 30 Aug 2011 10:05:50 +0200
Subject: What is the Best Way to Install Camping in 2011?
In-Reply-To: <CA+N_sa11ahc0g2Ve5u6ZjkvRFP1BSXGLMQsELzh=VVGrw1=2qw@mail.gmail.com>
References: <CA+N_sa11ahc0g2Ve5u6ZjkvRFP1BSXGLMQsELzh=VVGrw1=2qw@mail.gmail.com>
Message-ID: <CAA-yUx3Ev76WZFKTdv0DtwQw0dtZ-ruH+MYUbNSi-qrDEFuLZA@mail.gmail.com>

`gem install camping`

:D

(You may also want to install Markaby, ActiveRecord and all that.)

-- 
-- Matma Rex

From judofyr at gmail.com  Tue Aug 30 04:18:06 2011
From: judofyr at gmail.com (Magnus Holm)
Date: Tue, 30 Aug 2011 10:18:06 +0200
Subject: What is the Best Way to Install Camping in 2011?
In-Reply-To: <CA+N_sa11ahc0g2Ve5u6ZjkvRFP1BSXGLMQsELzh=VVGrw1=2qw@mail.gmail.com>
References: <CA+N_sa11ahc0g2Ve5u6ZjkvRFP1BSXGLMQsELzh=VVGrw1=2qw@mail.gmail.com>
Message-ID: <CAJ367fdNcTHx7n38A6E8Oq92R1=smZ_VYgbqcYnpLVfPvLBTMA@mail.gmail.com>

We definitely need to put out a new release. Try this in the meantime:

  gem install camping --source http://gems.judofyr.net/

(I've just updated the DNS record, so it might take an hour or two to
propagate correctly)

// Magnus Holm


On Tue, Aug 30, 2011 at 07:09, John Beppu <john.beppu at gmail.com> wrote:

> Let's say I have a pristine Unixy system in front of me.  (In my case, it's
> a new OS X 10.7 installation and I put MacPorts on there.)
>
> What is the simplest way to get an up-to-date Camping installation?
>
> (I've been out of the Ruby loop for a while.)
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110830/5f373e12/attachment-0001.html>

From timuckun at gmail.com  Tue Aug 30 06:35:58 2011
From: timuckun at gmail.com (Tim Uckun)
Date: Tue, 30 Aug 2011 22:35:58 +1200
Subject: What is the Best Way to Install Camping in 2011?
In-Reply-To: <CA+N_sa11ahc0g2Ve5u6ZjkvRFP1BSXGLMQsELzh=VVGrw1=2qw@mail.gmail.com>
References: <CA+N_sa11ahc0g2Ve5u6ZjkvRFP1BSXGLMQsELzh=VVGrw1=2qw@mail.gmail.com>
Message-ID: <CAGuHJrM+9_8inx3OQM=fOWacOPC-HjCfk_Z+0oJzeLd2TG_Eag@mail.gmail.com>

On Tue, Aug 30, 2011 at 5:09 PM, John Beppu <john.beppu at gmail.com> wrote:
> Let's say I have a pristine Unixy system in front of me. ?(In my case, it's
> a new OS X 10.7 installation and I put MacPorts on there.)
> What is the simplest way to get an up-to-date Camping installation?
> (I've been out of the Ruby loop for a while.)


step 1. Install RVM

$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

step 2. Install ruby

rvm install 1.9.2

step 3. Install camping

gem install camping.

Voila!

From timuckun at gmail.com  Tue Aug 30 06:40:45 2011
From: timuckun at gmail.com (Tim Uckun)
Date: Tue, 30 Aug 2011 22:40:45 +1200
Subject: A question about the ecosystem.
Message-ID: <CAGuHJrNz_meOW54UoStqrtng47PTwn8-LNkK9hh+wwq1wv2ZUw@mail.gmail.com>

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.

From a at creativepony.com  Tue Aug 30 06:56:27 2011
From: a at creativepony.com (Jenna Fox)
Date: Tue, 30 Aug 2011 20:56:27 +1000
Subject: A question about the ecosystem.
In-Reply-To: <CAGuHJrNz_meOW54UoStqrtng47PTwn8-LNkK9hh+wwq1wv2ZUw@mail.gmail.com>
References: <CAGuHJrNz_meOW54UoStqrtng47PTwn8-LNkK9hh+wwq1wv2ZUw@mail.gmail.com>
Message-ID: <925E1D6B-EF49-497E-B9B5-2D8CFB92C215@creativepony.com>

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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From dsusco at gmail.com  Tue Aug 30 09:33:19 2011
From: dsusco at gmail.com (David Susco)
Date: Tue, 30 Aug 2011 09:33:19 -0400
Subject: A question about the ecosystem.
In-Reply-To: <925E1D6B-EF49-497E-B9B5-2D8CFB92C215@creativepony.com>
References: <CAGuHJrNz_meOW54UoStqrtng47PTwn8-LNkK9hh+wwq1wv2ZUw@mail.gmail.com>
	<925E1D6B-EF49-497E-B9B5-2D8CFB92C215@creativepony.com>
Message-ID: <CAC2piVdxS7cA4Oy_Dyq0Dz-2-5SHWiwk9vxK9mu6+xWSCi_ogg@mail.gmail.com>

I've got five camping apps in production. They're mostly CRUDs with
some basic searching/e-mailing/etc. I use a few third party libraries;
haml, paper_trail, rack/csrf and redcloth being the main ones. I
haven't had too much need beyond those but your mileage will vary
obviously.

What Camping lacks is a lot of the fluff, but that's what I like the
most about it. It keeps things simple.

Dave

On Tue, Aug 30, 2011 at 6:56 AM, Jenna Fox <a at creativepony.com> wrote:
> 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 at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Dave

From judofyr at gmail.com  Tue Aug 30 14:15:47 2011
From: judofyr at gmail.com (Magnus Holm)
Date: Tue, 30 Aug 2011 20:15:47 +0200
Subject: Using CouchDB in Camping - looking for advice
In-Reply-To: <EE91F9D4729A4434AF255B577F4D0CFE@gmail.com>
References: <67B42A12D5C949CFAC2C43457B95EC41@gmail.com>
	<CAJ367fe5+CVE1vZa87behhcixZ+=WV0cUvUZmjXGFDTW50FnnQ@mail.gmail.com>
	<EE91F9D4729A4434AF255B577F4D0CFE@gmail.com>
Message-ID: <CAJ367fc3sK-iSYukM7mZMaw-MNQY1Rv=8E=zLfEOwZeF+NOMCw@mail.gmail.com>

On Mon, Aug 29, 2011 at 05:39, Daniel Bryan <danbryan at gmail.com> wrote:

> Woah, that sounds pretty cool. Are you using RubyParser or Ripper?
>
> Neither. I'm using sourcify (
> http://rubydoc.info/gems/sourcify/0.5.0/frames ) to convert blocks into an
> S Expression, and then my own library to parse that and spit out equivalent
> JavaScript syntax. I've made no attempt to deal with Ruby syntax that has no
> direct JS equivalent (like block arguments to function calls), nor to
> capture operations that would be illegal in JavaScript -
> https://github.com/cerales/ShyRubyJS
>

Very interesting!

>
> What if you introduce the concept of *contexts*? So all CouchDocument are
> automatically one context (that only include one type of document), but you
> can also introduce your own contexts. So you can have a CookingUser-context,
> which describes a User and what he can do with Receipes. In your controller
> you can say `CookingUser.new(current_user).untried_recepies`. Or maybe a
> UserReceipes which has an "untried"-view.
>
> So contexts are just a lightweight class where you can place your views.
> The developer has to decide what the context should be called and how they
> should work. The point is that the contexts should mirror the use-cases of
> the data, and as there might be many ways to look at the same data, you
> can't have an automatic way of saying where the view belongs. It all depends
> on the point-of-view.
>
>
> I like this!
>
> The way I'm interpreting this is that contexts could be a really light
> layer on top of the anonymous views. So it'd have your abstract view
> specification - a map block and a view block - and then a couple of little
> links specifying, for example, which model classes / "kinds" it's associated
> with, for the sake of the developer's sanity.
>
> When I started development on this concept, I put a lot of thought into how
> models would be written, to the point that they became effectively a schema.
> I realised that that was absurd - anything heavier than the optional "needs"
> and "suggests" concepts is throwing away the agility, convenience and
> forgiveness of a NoSQL approach.
>
> So that's out the window, but there's still a challenge here - model
> schemas, as well as being a concession to the brutality of SQL and its
> greedy demands, are a very useful tool for keeping track of and
> self-documenting your application. It seems there needs to be some kind of
> tool to replace that if your'e doing something like this.
>

The truth is that there is no such thing as "schema-less". There will always
be a schema. The question is if it will be enforced in the database, at
insert-time in code (each document has a strict schema) or at runtime in
code (it works just as a Hash).


>
> So what I'm thinking might be useful is some kind of optional admin
> interface that will look at your Models and your Views and your Contexts,
> and try to visualise or contextualise them in some way. Like the django
> admin interface, with all the power of introspection, but somehow groovy.
>
> Of course, it's so _easy_ to work with data when it's just JSON documents
> that there's no reason you couldn't, with a little thought, build a super
> user-friendly interface where you build your MapReduce views just by being
> given a graphical view of your document Kinds and dragging and dropping
> things into the fields for what you want to emit, what you want to filter,
> etc. It's probably not the best idea philosophically, but for giving people
> the tools to really easily write a dynamic web app it seems like it could be
> useful.
>

I've been thinking about the exact same concept, but a more general solution
based on relational algebra. My idea was that you defined your schema,
relationships and queries in an admin-panel thingie (inspired from Yahoo!
Pipes) in a database-agnostic way (relational model), and then later defined
the mapping from the database (which could be CouchDB, MongoDB, MySQL,
Redis) to the conceptual schema.

I'd say your project is more limited, but way more feasible than my "big
plan". So I think you should definitely go for it and make a kick-ass
CouchDB platform :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110830/49dd9bc3/attachment.html>

From timuckun at gmail.com  Tue Aug 30 18:20:52 2011
From: timuckun at gmail.com (Tim Uckun)
Date: Wed, 31 Aug 2011 10:20:52 +1200
Subject: A question about the ecosystem.
In-Reply-To: <CAC2piVdxS7cA4Oy_Dyq0Dz-2-5SHWiwk9vxK9mu6+xWSCi_ogg@mail.gmail.com>
References: <CAGuHJrNz_meOW54UoStqrtng47PTwn8-LNkK9hh+wwq1wv2ZUw@mail.gmail.com>
	<925E1D6B-EF49-497E-B9B5-2D8CFB92C215@creativepony.com>
	<CAC2piVdxS7cA4Oy_Dyq0Dz-2-5SHWiwk9vxK9mu6+xWSCi_ogg@mail.gmail.com>
Message-ID: <CAGuHJrNqCescdJyY417SVKH-0EzVxoxhFa6H9Fp6ZG0B6HtZMA@mail.gmail.com>

On Wed, Aug 31, 2011 at 1:33 AM, David Susco <dsusco at gmail.com> wrote:
> I've got five camping apps in production. They're mostly CRUDs with
> some basic searching/e-mailing/etc. I use a few third party libraries;
> haml, paper_trail, rack/csrf and redcloth being the main ones. I
> haven't had too much need beyond those but your mileage will vary
> obviously.
>
> What Camping lacks is a lot of the fluff, but that's what I like the
> most about it. It keeps things simple.
>

I like the promise of simplicity too.  What are you using for
Authentication?  Does simple_form or formtastic work with camping or
do you use something else for that?  I like Typus as a quick way to
put up admin sites does anybody know if it works with camping? Has
anybody tried whenever?

I presume will paginate, chronic etc will work as long as I stick with
AR (although honestly I want to try something other than AR too).

From a at creativepony.com  Tue Aug 30 19:49:34 2011
From: a at creativepony.com (Jenna Fox)
Date: Wed, 31 Aug 2011 09:49:34 +1000
Subject: A question about the ecosystem.
In-Reply-To: <CAGuHJrNqCescdJyY417SVKH-0EzVxoxhFa6H9Fp6ZG0B6HtZMA@mail.gmail.com>
References: <CAGuHJrNz_meOW54UoStqrtng47PTwn8-LNkK9hh+wwq1wv2ZUw@mail.gmail.com>
	<925E1D6B-EF49-497E-B9B5-2D8CFB92C215@creativepony.com>
	<CAC2piVdxS7cA4Oy_Dyq0Dz-2-5SHWiwk9vxK9mu6+xWSCi_ogg@mail.gmail.com>
	<CAGuHJrNqCescdJyY417SVKH-0EzVxoxhFa6H9Fp6ZG0B6HtZMA@mail.gmail.com>
Message-ID: <E8C79214-D447-4EB3-A66A-242A7C453198@creativepony.com>

I don't know about any of that, but in regards to authentication, I just use openid! It only takes about twenty lines in a controller to support, and is secure (even if you don't have https on your site), saves your users time, respects their privacy, means you don't need to worry about safely storing passwords or any other secrets, and you don't have to build login/signup/password reset forms - one simple copy pasteable controller, one login form, and you're done!

I stuck my openid code up here: http://creativepony.com/archive/journal/scripts/camping-openid-consumer/ - you'll also need the openid rubygem

?
Jenna



On 31/08/2011, at 8:20 AM, Tim Uckun wrote:

> On Wed, Aug 31, 2011 at 1:33 AM, David Susco <dsusco at gmail.com> wrote:
>> I've got five camping apps in production. They're mostly CRUDs with
>> some basic searching/e-mailing/etc. I use a few third party libraries;
>> haml, paper_trail, rack/csrf and redcloth being the main ones. I
>> haven't had too much need beyond those but your mileage will vary
>> obviously.
>> 
>> What Camping lacks is a lot of the fluff, but that's what I like the
>> most about it. It keeps things simple.
>> 
> 
> I like the promise of simplicity too.  What are you using for
> Authentication?  Does simple_form or formtastic work with camping or
> do you use something else for that?  I like Typus as a quick way to
> put up admin sites does anybody know if it works with camping? Has
> anybody tried whenever?
> 
> I presume will paginate, chronic etc will work as long as I stick with
> AR (although honestly I want to try something other than AR too).
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110831/686a8631/attachment-0001.html>

From edheil at fastmail.fm  Tue Aug 30 20:31:19 2011
From: edheil at fastmail.fm (Ed Heil)
Date: Tue, 30 Aug 2011 19:31:19 -0500
Subject: A question about the ecosystem.
In-Reply-To: <E8C79214-D447-4EB3-A66A-242A7C453198@creativepony.com>
References: <CAGuHJrNz_meOW54UoStqrtng47PTwn8-LNkK9hh+wwq1wv2ZUw@mail.gmail.com>
	<925E1D6B-EF49-497E-B9B5-2D8CFB92C215@creativepony.com>
	<CAC2piVdxS7cA4Oy_Dyq0Dz-2-5SHWiwk9vxK9mu6+xWSCi_ogg@mail.gmail.com>
	<CAGuHJrNqCescdJyY417SVKH-0EzVxoxhFa6H9Fp6ZG0B6HtZMA@mail.gmail.com>
	<E8C79214-D447-4EB3-A66A-242A7C453198@creativepony.com>
Message-ID: <4E5D80D7.2030406@fastmail.fm>

whoa.  Cool.  Bookmarked. :)  That would have saved me a lot of time 
last time I was messing with Camping.  Thank you. :)


On 8/30/11 6:49 PM, Jenna Fox wrote:
> I don't know about any of that, but in regards to authentication, I 
> just use openid! It only takes about twenty lines in a controller to 
> support, and is secure (even if you don't have https on your site), 
> saves your users time, respects their privacy, means you don't need to 
> worry about safely storing passwords or any other secrets, and you 
> don't have to build login/signup/password reset forms - one simple 
> copy pasteable controller, one login form, and you're done!
>
> I stuck my openid code up here: 
> http://creativepony.com/archive/journal/scripts/camping-openid-consumer/ 
> - you'll also need the openid rubygem
>
> ---
> Jenna
>
>
>
> On 31/08/2011, at 8:20 AM, Tim Uckun wrote:
>
>> On Wed, Aug 31, 2011 at 1:33 AM, David Susco <dsusco at gmail.com 
>> <mailto:dsusco at gmail.com>> wrote:
>>> I've got five camping apps in production. They're mostly CRUDs with
>>> some basic searching/e-mailing/etc. I use a few third party libraries;
>>> haml, paper_trail, rack/csrf and redcloth being the main ones. I
>>> haven't had too much need beyond those but your mileage will vary
>>> obviously.
>>>
>>> What Camping lacks is a lot of the fluff, but that's what I like the
>>> most about it. It keeps things simple.
>>>
>>
>> I like the promise of simplicity too.  What are you using for
>> Authentication?  Does simple_form or formtastic work with camping or
>> do you use something else for that?  I like Typus as a quick way to
>> put up admin sites does anybody know if it works with camping? Has
>> anybody tried whenever?
>>
>> I presume will paginate, chronic etc will work as long as I stick with
>> AR (although honestly I want to try something other than AR too).
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org <mailto:Camping-list at rubyforge.org>
>> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110830/e5d04980/attachment.html>

From nerdfunk at gmail.com  Tue Aug 30 20:57:13 2011
From: nerdfunk at gmail.com (adam moore)
Date: Wed, 31 Aug 2011 09:57:13 +0900
Subject: A question about the ecosystem.
In-Reply-To: <E8C79214-D447-4EB3-A66A-242A7C453198@creativepony.com>
References: <CAGuHJrNz_meOW54UoStqrtng47PTwn8-LNkK9hh+wwq1wv2ZUw@mail.gmail.com>
	<925E1D6B-EF49-497E-B9B5-2D8CFB92C215@creativepony.com>
	<CAC2piVdxS7cA4Oy_Dyq0Dz-2-5SHWiwk9vxK9mu6+xWSCi_ogg@mail.gmail.com>
	<CAGuHJrNqCescdJyY417SVKH-0EzVxoxhFa6H9Fp6ZG0B6HtZMA@mail.gmail.com>
	<E8C79214-D447-4EB3-A66A-242A7C453198@creativepony.com>
Message-ID: <CADiCtxTUuUAHoiG+Pn6b5xtwgnJWBLNj2x5EX+VAy3L8c1vFdA@mail.gmail.com>

Will paginate recently added native Sinatra support, but camping may require
so e workarounds with regards to view handlers.

I must say, the camping list is super friendly and, although quiet, very
responsive when something crops up.

On Wednesday, August 31, 2011, Jenna Fox <a at creativepony.com> wrote:
> I don't know about any of that, but in regards to authentication, I just
use openid! It only takes about twenty lines in a controller to support, and
is secure (even if you don't have https on your site), saves your users
time, respects their privacy, means you don't need to worry about safely
storing passwords or any other secrets, and you don't have to build
login/signup/password reset forms - one simple copy pasteable controller,
one login form, and you're done!
>
> I stuck my openid code up here:
http://creativepony.com/archive/journal/scripts/camping-openid-consumer/ -
you'll also need the openid rubygem
> ?
> Jenna
>
>
> On 31/08/2011, at 8:20 AM, Tim Uckun wrote:
>
> On Wed, Aug 31, 2011 at 1:33 AM, David Susco <dsusco at gmail.com> wrote:
>
> I've got five camping apps in production. They're mostly CRUDs with
>
> some basic searching/e-mailing/etc. I use a few third party libraries;
>
> haml, paper_trail, rack/csrf and redcloth being the main ones. I
>
> haven't had too much need beyond those but your mileage will vary
>
> obviously.
>
> What Camping lacks is a lot of the fluff, but that's what I like the
>
> most about it. It keeps things simple.
>
>
> I like the promise of simplicity too.  What are you using for
> Authentication?  Does simple_form or formtastic work with camping or
> do you use something else for that?  I like Typus as a quick way to
> put up admin sites does anybody know if it works with camping? Has
> anybody tried whenever?
>
> I presume will paginate, chronic etc will work as long as I stick with
> AR (although honestly I want to try something other than AR too).
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>

-- 
----=^.^=---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110831/cd16d84f/attachment.html>

From a at creativepony.com  Tue Aug 30 23:15:04 2011
From: a at creativepony.com (Jenna Fox)
Date: Wed, 31 Aug 2011 13:15:04 +1000
Subject: Teaching
Message-ID: <941ED8BE-EBE4-4BC7-B241-8989115EDD31@creativepony.com>

Who here loves teaching?

I love teaching. I think there's nothing more fun than finding someone brand new to programming, and helping them out of the cockpit of freenode and dancing about, swinging around trees and giggling gleefully while downing endless bottles of cider and.. wait..

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'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.

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.

TL;DR; I want brains. Braaaaaains http://cl.ly/0i1Q3S0A1017470j2c2r


?
Bluebie
Freelance internet doofus

From deveritt at innotts.co.uk  Wed Aug 31 07:38:08 2011
From: deveritt at innotts.co.uk (Dave Everitt)
Date: Wed, 31 Aug 2011 12:38:08 +0100
Subject: Teaching
In-Reply-To: <941ED8BE-EBE4-4BC7-B241-8989115EDD31@creativepony.com>
References: <941ED8BE-EBE4-4BC7-B241-8989115EDD31@creativepony.com>
Message-ID: <D860A8F9-3E46-46D7-AD77-D13E077F7B2F@innotts.co.uk>

> 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. Braaaaaains http://cl.ly/0i1Q3S0A1017470j2c2r

lol

DaveE

From a at creativepony.com  Wed Aug 31 09:35:06 2011
From: a at creativepony.com (Jenna Fox)
Date: Wed, 31 Aug 2011 23:35:06 +1000
Subject: Teaching
In-Reply-To: <D860A8F9-3E46-46D7-AD77-D13E077F7B2F@innotts.co.uk>
References: <941ED8BE-EBE4-4BC7-B241-8989115EDD31@creativepony.com>
	<D860A8F9-3E46-46D7-AD77-D13E077F7B2F@innotts.co.uk>
Message-ID: <A6951EAB-1D32-4B6C-ACC3-CE6371C6BEB6@creativepony.com>

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. Braaaaaains http://cl.ly/0i1Q3S0A1017470j2c2r
> 
> lol
> 
> DaveE
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From dsusco at gmail.com  Wed Aug 31 09:50:01 2011
From: dsusco at gmail.com (David Susco)
Date: Wed, 31 Aug 2011 09:50:01 -0400
Subject: A question about the ecosystem.
In-Reply-To: <CAGuHJrNqCescdJyY417SVKH-0EzVxoxhFa6H9Fp6ZG0B6HtZMA@mail.gmail.com>
References: <CAGuHJrNz_meOW54UoStqrtng47PTwn8-LNkK9hh+wwq1wv2ZUw@mail.gmail.com>
	<925E1D6B-EF49-497E-B9B5-2D8CFB92C215@creativepony.com>
	<CAC2piVdxS7cA4Oy_Dyq0Dz-2-5SHWiwk9vxK9mu6+xWSCi_ogg@mail.gmail.com>
	<CAGuHJrNqCescdJyY417SVKH-0EzVxoxhFa6H9Fp6ZG0B6HtZMA@mail.gmail.com>
Message-ID: <CAC2piVdmDzHY4ogVwozB7amhDcP3JxYeOJhnPepMiCkARh5cHg@mail.gmail.com>

I had to tie into an LDAP db so I just used net/ldap and a class I wrote.

I had problems getting will_paginate to work. I eventually just hacked
together something else. It doesn't really amount to much more than
what I was having to do with will_paginate, so it works for me. :P

Dave

On Tue, Aug 30, 2011 at 6:20 PM, Tim Uckun <timuckun at gmail.com> wrote:
> On Wed, Aug 31, 2011 at 1:33 AM, David Susco <dsusco at gmail.com> wrote:
>> I've got five camping apps in production. They're mostly CRUDs with
>> some basic searching/e-mailing/etc. I use a few third party libraries;
>> haml, paper_trail, rack/csrf and redcloth being the main ones. I
>> haven't had too much need beyond those but your mileage will vary
>> obviously.
>>
>> What Camping lacks is a lot of the fluff, but that's what I like the
>> most about it. It keeps things simple.
>>
>
> I like the promise of simplicity too. ?What are you using for
> Authentication? ?Does simple_form or formtastic work with camping or
> do you use something else for that? ?I like Typus as a quick way to
> put up admin sites does anybody know if it works with camping? Has
> anybody tried whenever?
>
> I presume will paginate, chronic etc will work as long as I stick with
> AR (although honestly I want to try something other than AR too).
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Dave

From deveritt at innotts.co.uk  Wed Aug 31 13:02:23 2011
From: deveritt at innotts.co.uk (Dave Everitt)
Date: Wed, 31 Aug 2011 18:02:23 +0100
Subject: Teaching
In-Reply-To: <A6951EAB-1D32-4B6C-ACC3-CE6371C6BEB6@creativepony.com>
References: <941ED8BE-EBE4-4BC7-B241-8989115EDD31@creativepony.com>
	<D860A8F9-3E46-46D7-AD77-D13E077F7B2F@innotts.co.uk>
	<A6951EAB-1D32-4B6C-ACC3-CE6371C6BEB6@creativepony.com>
Message-ID: <9E5C1EA2-225B-4502-B0D9-3F158FA1D4E2@innotts.co.uk>

> Everyday is WhyDay. You should know this! :D

oh yeh - I forgot :-)

> I'll email you directly with infos later.

k

From theonetruewaffles at gmail.com  Wed Aug 31 19:21:09 2011
From: theonetruewaffles at gmail.com (Anonymous Waffles)
Date: Wed, 31 Aug 2011 16:21:09 -0700
Subject: Teaching
In-Reply-To: <9E5C1EA2-225B-4502-B0D9-3F158FA1D4E2@innotts.co.uk>
References: <941ED8BE-EBE4-4BC7-B241-8989115EDD31@creativepony.com>
	<D860A8F9-3E46-46D7-AD77-D13E077F7B2F@innotts.co.uk>
	<A6951EAB-1D32-4B6C-ACC3-CE6371C6BEB6@creativepony.com>
	<9E5C1EA2-225B-4502-B0D9-3F158FA1D4E2@innotts.co.uk>
Message-ID: <CAO7L_L4SLqFaah9FDo1CEE8RN95BO8d+BOLy0JJ0hLO+w7g07w@mail.gmail.com>

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 <deveritt at 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 at rubyforge.org
> http://rubyforge.org/mailman/**listinfo/camping-list<http://rubyforge.org/mailman/listinfo/camping-list>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110831/a73e349d/attachment.html>

From a at creativepony.com  Wed Aug 31 21:11:54 2011
From: a at creativepony.com (Jenna Fox)
Date: Thu, 1 Sep 2011 11:11:54 +1000
Subject: Teaching
In-Reply-To: <CAO7L_L4SLqFaah9FDo1CEE8RN95BO8d+BOLy0JJ0hLO+w7g07w@mail.gmail.com>
References: <941ED8BE-EBE4-4BC7-B241-8989115EDD31@creativepony.com>
	<D860A8F9-3E46-46D7-AD77-D13E077F7B2F@innotts.co.uk>
	<A6951EAB-1D32-4B6C-ACC3-CE6371C6BEB6@creativepony.com>
	<9E5C1EA2-225B-4502-B0D9-3F158FA1D4E2@innotts.co.uk>
	<CAO7L_L4SLqFaah9FDo1CEE8RN95BO8d+BOLy0JJ0hLO+w7g07w@mail.gmail.com>
Message-ID: <5DE41232-1976-4B2E-BA87-D792F845A8DB@creativepony.com>

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 <deveritt at 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
> 
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20110901/2df8c3d7/attachment.html>