On the subject, can anyone recommend where to rent an iphone 4 sim for the
UK for a month?
Cheers
Julian
@madlep
On 14 July 2011 20:17, Andrew Grimm wrote:
> What Ben said. They didn't charge me anything.
>
> Andrew
>
> On Thu, Jul 14, 2011 at 11:46 AM, Ben Hoskings wrote:
> > It's free these
There's also a system ruby at /usr/bin/ruby, whatever's installed by the
package manager (usually 1.8.7). That one bootstraps babushka.
I build 1.9 to /usr/local/bin/ruby, and babushka installs dot-files that put
/usr/local/bin before /usr/bin in the path, so ruby1.9 always shadows the
system r
Sweet!
Anyone else?
On 28/07/2011, at 4:22 PM, Florian Hanke wrote:
> Hey Ben,
>
> If we need to fill up time between talk X and pizzas I have a lightning talk
> about "Reloading running applications" (~5-10 mins).
>
> Cheers,
>
> --
> You received this message because you are subscribed t
Hey Ben,
If we need to fill up time between talk X and pizzas I have a lightning talk
about "Reloading running applications" (~5-10 mins).
Cheers,
--
You received this message because you are subscribed to the Google Groups "Ruby
or Rails Oceania" group.
To view this discussion on the web vis
Hi Ben Askins,
My name is Raj Mallesh, Technology Consultant in Innoppl Technologies. We
are start ups with 2 years of experience in Ruby on Rails at *affordable*
pricing.
Our contact information follows.
Raj Mallesh
Innoppl Technologies.
E-Mail: raj.mall...@innoppl.com
Phone: (520) 204-1682
S
Hey Ben,
If you do 1.9.2 from source and have only one ruby, how does that fit
with babushka needing a ruby to bootstrap itself?
Cheers,
Chris
On Thu, Jul 28, 2011 at 12:33 PM, Ben Hoskings wrote:
> My answer is kind of "don't run 2 versions; everything should be on 1.9.2
> anyway." :)
>
> I
Pity. Formal Fridays would've fit well...
On Jul 27, 4:47 pm, Florian Hanke wrote:
> Heh, it'd be fun if we all wore suits and ties for once, down to
> presentations using bullet points and ugly backgrounds ;)
--
You received this message because you are subscribed to the Google Groups "Ruby
o
Hello,
I'm someone who uses RVM in production. I'll respond to the bits in
the thread that struck me:
* I don't know about now following the Unix way of things - we ended
up using a system wide install for RVM (set :rvm_type, :system
) so it's all in /usr/local. Is that not Unixy enough?
* The "
Hi All
Flying Solo is an online community for those going it alone in
business. We're a tight-knit little company - 3 partners and some
editorial peeps - and we're looking for a super-reliable tech person
to join our team.
The person we’re after will be happy to take on a regular, reliable
new cl
>> You could install both, make sure one has a suffix set (so ruby becomes
>> ruby19, irb becomes irb19, etc).
>
> Didn't know about that.
> Won't it break stuff because we'd have to use explicitly 'ruby19' instead
> just 'ruby'?
And then, you could create some nifty shell scripts that manage your
It's a compile-time flag, so I think that Ruby will be built with the
expectation of using the suffix. You will need to tweak your deployment
commands to use the appropriate ruby, yes.
I've never done this on production, mind you - just on my previous dev machine
before I started with RVM.
--
> You could install both, make sure one has a suffix set (so ruby becomes
> ruby19, irb becomes irb19, etc).
>
Didn't know about that.
Won't it break stuff because we'd have to use explicitly 'ruby19' instead
just 'ruby'?
--
You received this message because you are subscribed to the Google Grou
My answer is kind of "don't run 2 versions; everything should be on 1.9.2
anyway." :)
I realise that's idealised, but I do think it's OK for there to be a cost to
running legacy stuff.
But that's a different discussion altogether. As for an actual answer, I'd just
use a separate server. If the
You could install both, make sure one has a suffix set (so ruby becomes ruby19,
irb becomes irb19, etc).
--
Pat
On 28/07/2011, at 2:15 PM, Dmytrii Nagirniak wrote:
> But what other options do we have to run 2 ruby versions?
--
You received this message because you are subscribed to the Googl
On Thu, Jul 28, 2011 at 2:15 PM, Dmytrii Nagirniak wrote:
>
> But what other options do we have to run 2 ruby versions?
>
>
In this case it's self-solving: for a small environment where you can easily
log in and manage it, and automation would be overkill, just use RVM.
For a large environment,
Michael, Ben,
I see what you mean now.
In case of "toy" production env (which most of us has) - I guess it doesn't
matter that much.
For the "real" large environment involving a lot of setup, maintenance and
many people - it's a difference.
But in the latter scenario it would probably be a singl
I don't mean setup difficulty - I agree RVM is really easy to set up.
I mean, if you have path issues on the production box, or something else
breaking the ruby runtime, it's an order of magnitude easier to debug if RVM
isn't involved, because there's no shell fiddling going on.
On 28/07/2011,
Do that twice for your two production instances, once for your showcase
environment, once for your test and ci environments.
Realise that you need to change something fundamental in your production
instance ("oh hey, let's add varnish") that you'll need to replicate down
the chain - move to puppet
> Ahh, reading Ivan's message, it's obvious now - to automatically select a
> ruby per project.
> Are there other common uses?
>
I think that's the primary one.
Ben, in terms of complexity, maybe I am missing something, but installing
RVM took me the least amount of time.
http://blog.approache.co
RVM Gemsets and bundles solve the same issues as far as I am concerned. They
are primarily used for selecting the dependencies for your application.
On Thursday, 28 July 2011 at 1:45 PM, Ben Hoskings wrote:
> I'm curious about the other side of this coin - what do you use your .rvmrcs
> for?
I'm curious about the other side of this coin - what do you use your .rvmrcs
for?
I've never found a use for .rvmrc (or gemsets), given that I pretty much bundle
everything.
—Ben
On 28/07/2011, at 1:33 PM, Simon Russell wrote:
> I work with Michael Pearson; I'm one of the people who torments
Ahh, reading Ivan's message, it's obvious now - to automatically select a ruby
per project.
Are there other common uses?
—Ben
On 28/07/2011, at 1:33 PM, Simon Russell wrote:
> I work with Michael Pearson; I'm one of the people who torments him by
> insisting on checking in .rvmrc files. I'm
I've not had any problems using RVM in production - we automate all our setup
with Chef (I know, it's painful), which actually introduced the requirement for
RVM as chef-client plays badly on 1.9, so our system ruby is 1.8.7 and all our
apps run on 1.9.2.
All deployment is with Capistrano, and
Part of it might centre around not knowing the tool very well, but then that's
the whole point. A production setup should be as simple as it can possibly be
(and no simpler). In production, RVM is accidental complexity.
I don't think it's a matter of "I feel it's wrong". It's that I don't want m
I work with Michael Pearson; I'm one of the people who torments him by
insisting on checking in .rvmrc files. I'm probably also one of the
people who doesn't have a problem with RVM in production, but I
haven't tried using some of the more recent releases. Certainly the
random changes don't help.
Which is what I said on the first email I sent to the thread. Michael
was talking specifically about sandboxing gems.
On Thursday, July 28, 2011, Dmytrii Nagirniak wrote:
>
> On 28 July 2011 12:25, Julio Cesar Ody wrote:
>
>
> @ Michael: agreed, that's what Bundler is for. Again, should you
> a
I automated my VPS installation of RVM and Ruby with Babushka:
https://github.com/chrisberkhout/babushka-deps/blob/master/system/rvm_system.rb
https://github.com/chrisberkhout/babushka-deps/blob/master/system/rvm_system_ruby19.rb
But it was a pain. When this ends up breaking I'll probably just
swi
On Thu, Jul 28, 2011 at 11:48 AM, Pat Allan wrote:
>
>
> But I certainly wouldn't want that complexity in a production environment -
> and have never seen it pushed as an ideal production tool. Mike: is anyone
> recommending RVM for production?
>
The third heading on the homepage is 'Production'.
On 28 July 2011 12:25, Julio Cesar Ody wrote:
> @ Michael: agreed, that's what Bundler is for. Again, should you
> always run your apps on the same version of Ruby, it is a waste of
> time.
>
That's not why RVM exists. If everything you run is on one ruby version then
there's no point of using R
@ Michael: agreed, that's what Bundler is for. Again, should you
always run your apps on the same version of Ruby, it is a waste of
time.
@ Pat: me neither. That usually fixes a lot of problems all around.
On Thu, Jul 28, 2011 at 12:22 PM, Pat Allan wrote:
> I don't like the idea of checked-in
I don't like the idea of checked-in .rvmrc files at all - granted, I don't work
with any large teams though :)
--
Pat
On 28/07/2011, at 12:15 PM, Michael Pearson wrote:
> The .rvmrc thing was the easiest to work around, and if we'd really needed
> them, I would have either hacked/forked RVM.
The .rvmrc thing was the easiest to work around, and if we'd really needed
them, I would have either hacked/forked RVM. I'm the only developer at my
work that thinks that .rvmrc checked into a repo is a bad idea :) (gemsets?
that's what bundler is for! and we're all using ruby-1.9.2 anyway!)
It wa
I was using RVM in production on a Linode for a project a few months ago
and it worked relatively well. Granted we really used it to install REE
and get the environment set up and no more but it worked well enough for
that. Of course we didn't use .rvmrc files or anything like that.
On 28/07/2
Yeah, I read it.
http://serverfault.com/questions/227510/is-it-possible-to-skip-rvmrc-confirmation
On Thu, Jul 28, 2011 at 11:59 AM, Michael Pearson wrote:
> On Thu, Jul 28, 2011 at 11:56 AM, Julio Cesar Ody
> wrote:
>>
>> P.S.: it's probably not flawless, but reasons not to use RVM in
>> pr
I agree that RVM is a godsend for development, and a pain in production.
We configure production environments using binary packages of Ruby where
possible, or manually compile if the packages are considered too old.
Perhaps RVM would shine in a production environment hosting many different Rub
On Thu, Jul 28, 2011 at 11:56 AM, Julio Cesar Ody wrote:
> P.S.: it's probably not flawless, but reasons not to use RVM in
> production more often than not come down to "I feel it's wrong". The
> rest seems to circle around not knowing the tool too well.
>
>
We originally used RVM in prod to get a
> Hah, okay... well, anyone beside the author of RVM, then?
>
Yeah. I actually use it on my very little Linode server.
Would be interested to know what are the exact problems people have with it
as I haven't encountered any.
It is probably not worth running RVM if you do any kind of "cloud" thin
The 32 people who upvoted him on SO?
Andrew
On Thu, Jul 28, 2011 at 11:54 AM, Pat Allan wrote:
> Hah, okay... well, anyone beside the author of RVM, then?
>
> --
> Pat
>
> On 28/07/2011, at 11:53 AM, Dmytrii Nagirniak wrote:
>
>> But I certainly wouldn't want that complexity in a production envi
*headdesk*
I really should have kept IRC / twitter logs of my arguments with him.
Let me count the ways:
- he recommends that you always use the absolute latest version, locking
to a particular 'stable' version is discouraged
- one time, he switched to Rubygems 1.6.2 because "somebody o
I think you think so because, as you put it, you're a newcomer to RVM.
There's a lot of ifs which may or may not apply to the server you're
running your applications on.
I know more developers who write Ruby based on the install they have
locally on their machines than developers who know the diff
Hah, okay... well, anyone beside the author of RVM, then?
--
Pat
On 28/07/2011, at 11:53 AM, Dmytrii Nagirniak wrote:
> But I certainly wouldn't want that complexity in a production environment -
> and have never seen it pushed as an ideal production tool. Mike: is anyone
> recommending RVM f
>
> But I certainly wouldn't want that complexity in a production environment -
> and have never seen it pushed as an ideal production tool. Mike: is anyone
> recommending RVM for production?
>
Just FYI
https://rvm.beginrescueend.com/rvm/myths/
Myth #4: RVM is only for development
One of the mos
For what it's worth: I'm a bit of a newbie when it comes to setting up Rails
servers and RVM really lead me up the garden path. Really regretted my time
with it on a production machine.
I think a lot of the problem with it is the way it interacts (or doesn't
interact) with permissions.
On Thu, Ju
As I said on your blog:
No, RVM isn't great for production.
And while Wayne hasn’t actually come out and said it, he runs RVM as a tool
for developers only: frequent updates, shit breaks every so often, moving
target, recommend that you always use the latest version, etc etc.
We had RVM on our U
Wayne E Seguin, the creator of RVM, said on SO that it was actually
designed for production
http://stackoverflow.com/questions/5864001/is-rvm-production-ready/6282260#6282260
I humbly disagreed at
http://stackoverflow.com/questions/5864001/is-rvm-production-ready/6286677#6286677
Still, it's more
I wouldn't develop without RVM these days - makes it easy to have legacy apps
on 1.8.7 and newer ones on 1.9.2 - and ditto for gem development as well.
But I certainly wouldn't want that complexity in a production environment - and
have never seen it pushed as an ideal production tool. Mike: is
I agree, I think RVM is fundamentally not suited to production. That is, I
think the things that make it a useful tool are exactly the kinds of things you
don't want in production.
I build from source. `babushka benhoskings:ruby19.src` :)
—Ben
On 28/07/2011, at 11:43 AM, Mike Bailey wrote:
>
It occurred to me that RVM *could* result in ops guys feeling like the
waiter in LA Story.
http://youtu.be/z-CrML0BzOA
"I'll have a half double decaffeinated half caf with a twist of lemon"
While RVM is great for developer workstations, to me it doesn't seem right
for production environments. A
Hi Craig
On Thu, Jul 28, 2011 at 10:35 AM, Craig Ambrose wrote:
> Hi folks,
>
> After upgrading to Lion, re-installing XCode, and image magic, and all
> that jazz, the parallel_tests gem is failing to work for me. I'm not
> sure if others are using this, but it's pretty darn handy, so I figure
>
Hi folks,
After upgrading to Lion, re-installing XCode, and image magic, and all
that jazz, the parallel_tests gem is failing to work for me. I'm not
sure if others are using this, but it's pretty darn handy, so I figure
you probably are.
The issue appears to be that parallel_tests uses the follo
tl;dr - Plus2 are looking for an experienced Ruby on Rails developer
for a 3 month contract to build a site delivering travel related
content to frequent business travellers. The client is a chain of
hotels across Asia and the Middle East.
The longer version
==
We're looking for s
51 matches
Mail list logo
