I've been playing with backupmyapp.com - they recently changed their
pricing model and made it much more viable - works fine with Heroku
too..that might be just the ticket for you
I'd imagine they're using s3 behind the scenes.
john.
On Jan 7, 7:18 pm, Matt Buck mattb...@capitalthought.com
Hmm... try unzipping the .gem and poking around. If you install all of the
dependencies minus the 'json' gem, it may work.
I don't work at Heroku, by the way.
--
You received this message because you are subscribed to the Google Groups "Heroku" group.
To post to this group, send email to
I'm currently working on getting the heroku gem running on as many
platforms as possible.
If anyone would like to get involved in this effort, the gem is open
source at http://github.com/heroku/heroku
- David
On Fri, Jan 8, 2010 at 2:32 AM, dan mr.dan.ma...@gmail.com wrote:
i was looking
Do you think there's any way we can remove the requirement of the 'json' gem
for 1.9? This is what appears to be causing the problem—Ruby 1.9 includes
the json library.
On Fri, Jan 8, 2010 at 8:36 AM, David Dollar da...@heroku.com wrote:
I'm currently working on getting the heroku gem running
It looks like json isn't necessarily 1.9 on every platform. We might
have to detect when using 1.9 and use the fake json gemspec talked about
here: http://isitruby19.com/json
Have you tried 1.8.6? Heroku currently runs 1.8.6 so it would make
sense to dev on ruby 1.8.6 instead of 1.9.1 since
Why can't you guys just give an option in the app config for the Ruby
version? We can already set gem versions for the app in the .gems manifest.
Doesn't this make sense?
Just my two cents.
--
~devyn
--
You received this message because you are subscribed to the Google Groups "Heroku" group.
My app uploads a file (via paperclip), and saves the file in
:rails_root/tmp/:id/:basename.:extension. Works perfectly.
After the file is successfully received and saved in tmp, I need to
run a script on it that may take 30-60 seconds. For now I just process
this within the current request cycle.
Hi everybody,
Im working on some RESTful web services witch will be running on
heroku, and currently trying to work out what is the best way to do
single sign on, so my main app will not need to authenticate with the
web services in order to access data.
they are all on the same domain -
I'm a complete and utter nooby, though not so new that I haven't run a
search or five on this list to find if anyone else is having this
problem.
I'm getting my feet wet with Heroku, Rails, and Git all at the same
time. I've got a couple of little projects going, each of which have
had the
Try the following
git rm public/index.html
git commit -m remove default index page
git push heroku
- David
On Fri, Jan 8, 2010 at 9:15 AM, JGrubb therealjohnnygr...@gmail.com wrote:
I'm a complete and utter nooby, though not so new that I haven't run a
search or five on this list to find if
Maybe, but there's no guarantee of that. The dyno that received the
request may be running on a totally different server than the worker
that processes it. In this case, you should upload the file to S3,
then download from S3 in the worker for processing.
Hope this helps,
David
On Fri, Jan 8,
You may also need to try:
heroku restart
I had the same problem a while back and once I restarted the server it fixed
the problem. I'm wondering if the index page was cache in Varnish perhaps?
Carl
On Fri, Jan 8, 2010 at 10:46 AM, David Dollar da...@heroku.com wrote:
Try the following
git
On Jan 8, 11:48 am, David Dollar da...@heroku.com wrote:
Maybe, but there's no guarantee of that. The dyno that received the
request may be running on a totally different server than the worker
that processes it. In this case, you should upload the file to S3,
then download from S3 in the
On rufus-scheduler, it looks like it simply creates a new ruby thread:
class PlainScheduler SchedulerCore
def start
@thread = Thread.new do
loop do
sleep(@frequency)
self.step
end
end
end
end
Would this remain on the same dyno as the
This wouldn't work on Heroku because even though it's in a different
thread it's still the same request, and we only allow requests to go
for 30s. This would tie up your dyno for the background request.
- David
On Fri, Jan 8, 2010 at 2:08 PM, Karl threadh...@gmail.com wrote:
On rufus-scheduler,
On Jan 8, 12:10 pm, David Dollar da...@heroku.com wrote:
This wouldn't work on Heroku because even though it's in a different
thread it's still the same request, and we only allow requests to go
for 30s. This would tie up your dyno for the background request.
So, wouldn't I have the same issue
Yeah, it's best to turn off caching while doing development. The easiest way
to do this is
# app/controllers/application_controller.rb
class ApplicationController # blah blah blah
# blah blah blah
after_filter :set_no_cache
private
def set_no_cache
headers['Cache-Control']
So, wouldn't I have the same issue with DJ and my process exceeding
30s?
What I've been doing is storing the files on S3, and then pulling them
down to the tmp directory on demand when my DJ process requests them.
All you have to do to copy a file from S3 to tmp (with Paperclip) is:
I was wondering if there's a way to turn off 'heroku db:push', or some
way to obscure the command. The reason I'm asking is because I am
deploying a second app to Heroku, and I was just thinking to myself,
gosh, if I accidentally typed 'heroku db:push' or 'heroku db:reset' on
my other app, all my
I should have put PREVENTING accidental 'heroku db:reset' - no, I
haven't done this yet. But I have nightmares about it.
On Jan 8, 8:59 pm, Ryan Heneise r...@donortools.com wrote:
I was wondering if there's a way to turn off 'heroku db:push', or some
way to obscure the command. The reason I'm
(Disclaimer: i don't work for Heroku)
Ryan - I haven't seen any such feature, but you could just read the heroku gem
source code and comment out those parts of the code that actually do the
db:push if you are that paranoid
On Jan 8, 2010, at 9:00 PM, Ryan Heneise wrote:
I should have put
With db:reset you get a scary prompt asking you if you're sure. This
is a good suggestion though.
- David
On Fri, Jan 8, 2010 at 9:00 PM, Ryan Heneise r...@donortools.com wrote:
I should have put PREVENTING accidental 'heroku db:reset' - no, I
haven't done this yet. But I have nightmares about
I suppose you could probably alias the command out in your .bashrc file or
something.
Carl
On Fri, Jan 8, 2010 at 6:05 PM, David Dollar da...@heroku.com wrote:
With db:reset you get a scary prompt asking you if you're sure. This
is a good suggestion though.
- David
On Fri, Jan 8, 2010 at
I suppose you could probably alias the command out in your .bashrc file or
something.
Carl - great idea.
I'm actually more worried about accidentally doing 'heroku db:push' -
as this would pretty much do the same thing as db:reset, just without
the scary prompt (I think - I'm not going to try
Anyone using Ruby 1.9 feeling adventurous?
Clone git://github.com/heroku/heroku.git, run rake spec, and let me
know if you're green or not.
- David
On Fri, Jan 8, 2010 at 12:24 PM, Devyn Cairns devyn.cai...@gmail.com wrote:
Why can't you guys just give an option in the app config for the Ruby
25 matches
Mail list logo
