Hello the Melbourne Ruby Meetup is on its way again - two weeks from today.
6pm for a 6:30 start until 9ish
Thoughtworks IOOF Building,
Level 15, corner of Elizabeth and Collins Street
Pat Allan is on the books to tell us about his new Flying Sphinx heroku
add-on, and Arunan is hopefully going
http://instagr.am/p/DI4sT/
Anyone?
--
You received this message because you are subscribed to the Google Groups "Ruby
or Rails Oceania" group.
To post to this group, send email to rails-oceania@googlegroups.com.
To unsubscribe from this group, send email to
rails-oceania+unsubscr...@googlegr
Hi guys. Thank you very much for both replays.
I did all the things you recommend me to do but I'm still having the
same error:
$ rvm -v
rvm 1.6.1 by Wayne E. Seguin (wayneeseg...@gmail.com) [https://
rvm.beginrescueend.com/]
$ ruby -v
ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0
In the logs:
"/Users/ric/.rvm/src/rubygems-1.4.2/setup.rb"',
It's still using rubygems-1.4.2
wayneeseguin, for some bloody annoying reason, rolled back the RVM default
rubygems to 1.4.2 for a couple of days until we all shouted at him on github
and IRC.
When did you update RVM? It should be ba
Relevant discussion:
https://github.com/wayneeseguin/rvm/commit/81b9dfa5002eb900405b0e6a2b5088d959cd7cbb#commitcomment-337167
So, if you updated RVM (with rvm get head && rvm reload) more than a couple
of days ago you'll be using rubygems-1.4.2
Re-run rvm get head && rvm reload, reinstall, and
Looks like those Heroku guys know how to party.
On Thursday, 14 April 2011 at 10:24 PM, Tim McEwan wrote:
> http://instagr.am/p/DI4sT/
>
> Anyone?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To post to this group, s
I have a design issue I want to walk through.
I'm building a Rails 3 app which will hold products from a variety of
different companies. I'd like to define a large set of fields and each
product can select the fields that are applicable to it.
The field types will be single line text fields, mult
Its a good way to go. We did something similar for a client rendering out
dynamic data.
The only thing l would do different is find a better way to define the fields
so that you dont have to manage them in the class but rather a more dynamic way
should the types of products change alot
On 15/
I'll probably keep the field definitions in code for now. To define them I'm
thinking a DSL along the lines of this:
*def field_definitions*
* FieldDefinitions.create do*
*category :tour do*
* single_line :code, :label => 'Code'*
* multiline :itinerary, :label => 'Itinerary'*
*
Here's my take:
class Stuff
fields do
singleline'code'
multiline 'itinerary'
age_range 'age', label: 'Infante age range'
options 'size', options: %w(Small Medium Large)
end
end
Some thoughts:
- Don't use symbols just because.
- Have label be extrapolated from
Sweet, i'll take it!
I still like symbols just because though...
On Fri, Apr 15, 2011 at 11:05 AM, Julio Cesar Ody wrote:
> Here's my take:
>
> class Stuff
> fields do
>singleline'code'
>multiline 'itinerary'
>age_range 'age', label: 'Infante age range'
>options
On 15/04/2011, at 11:14 AM, Dave Newman wrote:
I still like symbols just because though...
+1
Symbols don't look as nice, but they cost less, because Ruby doesn't
need to construct a new mutable instance every time you execute that
line of code, as it does with strings.
Not usually a problem
I'm all for what the author likes, so that's a good enough reason for
him to stick to symbols. But this being a DSL and all, and the fact
it'll be declared at load time, nice is what this should be all about
:)
On Fri, Apr 15, 2011 at 11:22 AM, Clifford Heath
wrote:
> On 15/04/2011, at 11:14 AM
On 15/04/2011, at 11:25 AM, Julio Cesar Ody wrote:
I'm all for what the author likes, so that's a good enough reason for
him to stick to symbols. But this being a DSL and all, and the fact
it'll be declared at load time, nice is what this should be all about
:)
Can't say I agree or disagree rea
+1 symbols. Not only are they immutable and more efficient, they look
prettier in textmate.
Robert
--
You received this message because you are subscribed to the Google Groups "Ruby
or Rails Oceania" group.
To post to this group, send email to rails-oceania@googlegroups.com.
To unsubscribe from
I agree - I say this is exactly what symbols are for, both functionally and
aesthetically.
Julio: perhaps you need to tweak your editor colour scheme? :)
On Fri, Apr 15, 2011 at 12:13 PM, Robert Gravina
wrote:
> +1 symbols. Not only are they immutable and more efficient, they look
> prettier in
I bet Julio uses strings because he is such a JS fiend.
--
Rufus Post
Sent with Sparrow
On Friday, 15 April 2011 at 12:23 PM, Paul Annesley wrote:
> I agree - I say this is exactly what symbols are for, both functionally and
> aesthetically.
>
> Julio: perhaps you need to tweak your editor col
You could have a relation for fields. Within that relation you would
store the field name, value and type. The type that would be used when
rendering the field. If you mapped your types directly to the rails
helpers you would not have to write any code... just have a validation
in your model that o
We've been doing a very similar thing with MongoDB and Mongoid
(http://mongoid.org)
If you set your own "custom attributes" as key value pairs on the document then
an ODM (such as mongoid) will automatically create getters and setters for
those keys.
Meaning you effectively don't have to defin
19 matches
Mail list logo
