Imminent Death of the Heroku Google Group

[Alex Chaffee]

fIn the latest Heroku Newsletter[1], it says this group will be killed
at the end of April, and suggests instead to go to support.heroku.com
(which is private) or stackoverflow.com. While SO is awesome, is it
really an adequate replacement for this group? I've found that SO is a
great complement to mailing lists but doesn't allow for the same kind
of deep discussion and community building. Worse, it requires active
attention rather than arriving in one's inbox, so the people who are
most likely to have an answer to a question are the least likely to
hear it -- since they're not having any problems.

Why uproot a productive community (this mailing list) and hope that it
migrates to a new place with a radically different interaction model?

[1] 
http://lists.heroku.com/t/ViewEmail/r/6DFC781E555FD71E/CEC5941F8B0A6F4BC5EC08CADFFC107B

-- 
Alex Chaffee - a...@stinky.com
http://alexchaffee.com
http://twitter.com/alexch

-- 
You received this message because you are subscribed to the Google
Groups "Heroku" group.

To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en_US?hl=en

Re: Background job guidance

[Alex Chaffee]

I rolled my own background job processor using CouchDB. Procfiles and 
Foreman and the Cedar process model make it very simple. I can even scale 
up and down using the Heroku API from inside a running Heroku web process; 
I think the Resque systems I saw described don't allow you to scale down to 
0 workers but mine does.

Check the code at https://github.com/alexch/sharebro, especially

https://github.com/alexch/sharebro/blob/master/spec/ant_spec.rb
https://github.com/alexch/sharebro/blob/master/lib/ant.rb
https://github.com/alexch/sharebro/blob/master/work.rb

If anyone's interested I could collaborate on pulling it out into yet 
another gem, but for now it's stuck in this app (and a couple other private 
ones).

For an arguably better system see 
http://blog.leshill.org/blog/2011/04/03/using-resque-and-resque-scheduler-on-heroku.html
https://github.com/ajmurmann/resque-heroku-autoscaler

but I didn't want to add Redis and Resque -- I prefer the devil I know 
cause I created him :-)

 - A

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/heroku/-/M48-ZnFTvG8J.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

Re: [ANN] rerun 0.6.3 released, with foreman/Procfile support

[Alex Chaffee]

BUGFIX:
as of rerun 0.6.3, it polls 1x/sec for keyboard input (e.g. "c" to
clear the screen). This polling requires a momentary setting of the
tty to "raw" mode which unfortunately affects both input and output
streams. So *sometimes* for *brief moments* your output loses the
ability to turn "LF" into "CRLF", and things get all messy.
rerun 0.6.5 fixes this. Your output logs should be as clean as a fresh
snowfall and as margin-aligned as an illuminated manuscript.
Only tested on Mac OS X Lion. Please let me know if other systems
require other stty tweaks.
And since this is the Heroku list, let me re-pose the question: Is
rerun now the only one of the myriad "restarter" tools with support
for restarting foreman (worker procs) in development?
 - A


On Sun, Nov 27, 2011 at 1:14 PM, Alex Chaffee  wrote:
> rerun 0.6.3 released
> http://github.com/alexch/rerun
> == Description:
> Rerun launches your program, then watches the filesystem. If a
> relevant filechanges, then it restarts your program.
> Rerun works for both long-running processes (e.g. apps) and
> short-running ones(e.g. tests). So it works like shotgun and autotest
> (and guard and all therest).
> Rerun's advantage is its simple design. Since it uses standard Unix
> "SIGINT"and "SIGKILL" signals, you're sure the restarted app is really
> acting justlike it was when you ran it from the command line the first
> time.
> == New features:
> * better signal handling
> * support for "foreman" and Heroku Cedar apps  (And hey, does Shotgun
> reload your Worker processes if you're using Foreman  and a Procfile?
> I don't think it does...)
> * On-The-Fly Commands
>   While the app is (re)running, you can make things happen by pressing keys:
>   r - restart (as if a file had changed)  c - clear the screen  x -
> exit (just like control-C)
>
> --
> Alex Chaffee - a...@stinky.com
> http://alexchaffee.com
> http://twitter.com/alexch



-- 
Alex Chaffee - a...@stinky.com
http://alexchaffee.com
http://twitter.com/alexch

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

[ANN] rerun 0.6.3 released, with foreman/Procfile support

[Alex Chaffee]

rerun 0.6.3 released
http://github.com/alexch/rerun
== Description:
Rerun launches your program, then watches the filesystem. If a
relevant filechanges, then it restarts your program.
Rerun works for both long-running processes (e.g. apps) and
short-running ones(e.g. tests). So it works like shotgun and autotest
(and guard and all therest).
Rerun's advantage is its simple design. Since it uses standard Unix
"SIGINT"and "SIGKILL" signals, you're sure the restarted app is really
acting justlike it was when you ran it from the command line the first
time.
== New features:
* better signal handling
* support for "foreman" and Heroku Cedar apps  (And hey, does Shotgun
reload your Worker processes if you're using Foreman  and a Procfile?
I don't think it does...)
* On-The-Fly Commands
  While the app is (re)running, you can make things happen by pressing keys:
  r - restart (as if a file had changed)  c - clear the screen  x -
exit (just like control-C)

-- 
Alex Chaffee - a...@stinky.com
http://alexchaffee.com
http://twitter.com/alexch

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

How can I scale my worker processes from inside a web process?

[Alex Chaffee]

(was "Can I issue a "heroku restart" from within my app that's running on 
Heroku")

Neil, you read my mind! Thanks for the answer. My only regret is that it's 
buried in a thread with advice for some poor soul who wants to use 
heroku:restart. Oh wait, I can rename the thread! :-)

How about "How can I call the Heroku API from inside my Heroku app?"

or "How can I have my web process "scale up" and "scale down" my worker 
process?"

I want to do this in response to a web request, so I don't have to pay for 
my worker process being awake 24/7.

Here's what I got:

# Gemfile

gem 'heroku'


# unix command line

heroku config:add HEROKU_APP_NAME="myapp" \
 HEROKU_EMAIL="m...@example.com" \
 HEROKU_PASSWORD="secret"


# ruby

require 'heroku'
heroku = Heroku::Client.new(ENV["HEROKU_EMAIL"], ENV["HEROKU_PASSWORD"])
heroku.ps_scale(ENV["HEROKU_APP_NAME"], :type => "worker", :qty => 1)


If you don't want your app to be able to access all your other apps -- 
maybe you're on a team of untrustworthy rapscallions -- then sign up for a 
new heroku account with a new email address and password, and then add that 
heroku account as a collaborator.

I can point you to github source once I'm sure it all works in my latest 
app.

 - A

P.S. Thanks to https://github.com/pcapr/dyno-blitzer/issues/3 for 
deciphering the 422 error.

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/heroku/-/Ns6_CvJ4yHIJ.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

[addon] Cloudant CouchDB Futon - formatting problem and fix

[Alex Chaffee]

   
   First, in case you don't know, CouchDB calls its admin console "Futon". 
   Yes, it's a stupid name for an admin console. Anyway.
   
   Cloudant's Heroku console (https://cloudant.com/futon/database.html once 
   you're logged in) wraps the normal couchdb futon in some extra HTML, 
   showing the heroku header and a Cloudant 'overview'. Unfortunately this 
   pushes down the main futon content so that even when you're scrolled down 
   all the way, on long pages, you can't see the futon controls ('showing 1-82 
   of 82 rows' and the 'rows per page' and 'next page' widgets). 
   
   I've reported this to Cloudant but in the meantime this trivial 
   bookmarklet fixes it by giving the 'wrap' div a height of 88% instead of 
   100%.
   
   http://alexchaffee.com/bookmarklets/#fixcloudantherokuconsole
   
It'd be better as a userscript but for now you have to click it every time 
you can't see the bottom of your page.

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/heroku/-/XFsJSh38-JsJ.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

Deploying an app on behalf of a third party

[Alex Chaffee]

Dear Heroku -

I've developed a set of test-first ruby training exercises at
http://testfirst.org and I've been brainstorming about how to take it to the
next level. I've been imagining an interactive web site, where users can
edit code and run RSpec tests from inside their web browser.

Unfortunately (for me and for the whole world) the SCRIPT tag only supports
JavaScript on most browsers. So I'd have to send the students' code to a web
server and execute it there.

The problem with that is security. The code is all open source and I won't
be storing any sensitive information, so I'm not worried about malicious
crackers[1], but there's still a risk that a student could, accidentally or
on purpose, break or otherwise compromise the functionality of the app if
I'm evaling arbitrary code on their behalf.

I know about $SAFE but I don't think it's actually safe enough for this
purpose. I've also heard of Why's Freaky Sandbox but I couldn't find the
code anywhere (R.I.P.)

So I had a thought: what if I have a master app, and a student could connect
to it, temporarily give me his Heroku credentials, and then I could spin up
a lab app under his Heroku account that only he knows the URL to. Anything
he breaks would just affect his own instance, and I could have a big "reset"
button that could clean up ("heroku restart") after that. I'd still use
$SAFE to stop access to the filesystem, but even that wouldn't be very
risky.

Is there a way to do this cleanly? Say, with a Heroku OAuth API?

Oh, wait, I think I just figured it out!

I can't create an app with the user's credentials. But I can create an app
with *my* credentials (SSH keys) and then transfer ownership to the user
(after appropriate email validation, of course).

So I guess now my question becomes, can I use the heroku gem or CLI from
inside a running heroku app?

 - A

[1] not nearly as tasty as Animal Crackers.

(cc'ing the test-first-teaching google group in case someone there has any
bright ideas or wants to contribute)

-- 
Alex Chaffee - a...@stinky.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

Re: Anyone having trouble using heroku console?

[Alex Chaffee]

Rake 0.9.x no longer includes the DSL module in the top level
namespace. So another solution to the "uninitialized constant
Rake::DSL" problem is to explicitly include the DSL module in your
Rakefile, near the top, like this:

require "rake"
include Rake::DSL

It's more or less fixed now (with Rake 0.9.2 and Rails 3.0.9) but it's
been a total clusterfrack and a great example of a poor release
process.

On Jul 14, 10:53 am, Terence Lee  wrote:
> Hello Keenan,
>
> It's because rake is built into ruby 1.9.2 and the version is 0.8.7 and
> that's the one being called here. We're looking into ways to fix this. In
> the meantime, can you try hard coding your rake to 0.8.7 in your Gemfile?
> Once you have that working locally, it should work fine on heroku.
>
> Best,
> Terence
>
>
>
>
>
>
>
> On Wed, Jul 13, 2011 at 9:06 AM, Keenan Brock  wrote:
> >  Hi,
>
> > Question: Are others able to run: heroku rake db:migrate OR heroku console
> > "puts Model.count" ?
>
> > This is probably user error, but I can't figure it out. reminds me of not
> > specifying RAILS_ENV when running rails console.
>
> > I had run rake db:seed which populated the Avatar model.
> > I view a page on the website that relies upon the Avatar model.
> > I ran heroku config:add RAILS_ENV=production (just in case)
>
> > But from heroku console:
>
> > *> puts Avatar.count*
> > ActiveRecord::StatementInvalid: PGError: ERROR:  relation "avatars" does
> > not exist
> > :             SELECT a.attname, format_type(a.atttypid, a.atttypmod),
> > d.adsrc, a.attnotnull
> >               FROM pg_attribute a LEFT JOIN pg_attrdef d
> >                 ON a.attrelid = d.adrelid AND a.attnum = d.adnum
> >              WHERE a.attrelid = '"avatars"'::regclass
> >                AND a.attnum > 0 AND NOT a.attisdropped
> >              ORDER BY a.attnum
>
> > /app/.bundle/gems/ruby/1.9.1/gems/activerecord-3.0.9/lib/active_record/conn 
> > ection_adapters/abstract_adapter.rb:207:in
> > `rescue in log'
> > /app/.bundle/gems/ruby/1.9.1/gems/activerecord-3.0.9/lib/active_record/conn 
> > ection_adapters/abstract_adapter.rb:199:in
> > `log'
> > /app/.bundle/gems/ruby/1.9.1/gems/activerecord-3.0.9/lib/active_record/conn 
> > ection_adapters/postgresql_adapter.rb:501:in
> > `query'
> > /app/.bundle/gems/ruby/1.9.1/gems/activerecord-3.0.9/lib/active_record/conn 
> > ection_adapters/postgresql_adapter.rb:1037:in
> > `column_definitions'
>
> > *> heroku rake db:migrate*
>
> > (in /app)
> > rake aborted!
> > uninitialized constant Rake::DSL
> > /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2482:in `const_missing'
> > /app/.bundle/gems/ruby/1.9.1/gems/rake-0.9.2/lib/rake/tasklib.rb:8:in
> > `'
> > /app/.bundle/gems/ruby/1.9.1/gems/rake-0.9.2/lib/rake/tasklib.rb:6:in
> > `'
> > /app/.bundle/gems/ruby/1.9.1/gems/rake-0.9.2/lib/rake/tasklib.rb:3:in ` > (required)>'
> > /app/.bundle/gems/ruby/1.9.1/gems/rdoc-3.8/lib/rdoc/task.rb:37:in `require'
> > /app/.bundle/gems/ruby/1.9.1/gems/rdoc-3.8/lib/rdoc/task.rb:37:in ` > (required)>'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks/documentat 
> > ion.rake:2:in
> > `require'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks/documentat 
> > ion.rake:2:in
> > `'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:15:in
> > `load'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:15:in
> > `block in '
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:6:in
> > `each'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:6:in
> > `'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/application.rb:2 
> > 15:in
> > `require'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/application.rb:2 
> > 15:in
> > `initialize_tasks'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/application.rb:1 
> > 39:in
> > `load_tasks'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/application.rb:7 
> > 7:in
> > `method_missing'
> > /app/Rakefile:7:in `'
> > /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2373:in `load'
> > /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2373:in `raw_load_rakefile'
> > /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2007:in `block in load_rakefile'
> > /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2058:in `standard_exception_handling'
> > /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2006:in `load_rakefile'
> > /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:1991:in `run'
> > /usr/ruby1.9.2/bin/rake:31:in `'
>
> > Thanks for any pointers on what I am doing wrong,
> > Keenan
>
> > --Keenan
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Heroku" group.
> > To post to this group, send email to heroku@googlegroups.com.
> > To unsubscribe from this group, send email to
> > heroku+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/heroku?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"He

Re: uninitialized constant Rake::DSL

[Alex Chaffee]

YMMV, but I'm pretty sure Rake 0.9.2 fixes this.

Another solution is to add the following to your Rakefile, right after
"require 'rake'"

class Rails::Application
  include Rake::DSL
end

(from memory; please let me know if it doesn't work and I'll look it
up for you)


On Jun 17, 7:01 pm, Daniel Myasnikov 
wrote:
> Hey
>
> I had the same issue, and the whole yesterday to solve it.
>
> First of all, if you are using Rake 0.8.7 and put "require 'rake/
> dsl_definition'" it won't work for you. This feature was introduced
> for Rake 0.9.x.
>
> I strongly recommend to use Rake 0.8.7
>
> and get rid out of everything that you put for rake 0.9.x, such as
> 'include Rake:dsl' and extend Rake::FileUtilsExt
>
> So your RakeFile file should look like:
>
> require File.expand_path('../config/application', __FILE__)
>
> require 'rake'
>
> MyApplicationName::Application.load_tasks
>
> 2. Secondly check if you have installed Rake 0.9.x and remove it from
> your computer and use Rake 0.8.7, which you have to install before
> using
>
> 3. Use gem "rake", "0.8.7" in your GemFile just after source 'http://
> rubygems.org'
>
> 4. Make sure your gem for rails is '3.0.9'
>
> 5. Some said that this gem also helped them gem 'sqlite3',
> '1.3.3', :group => :development
>
> Also don't forget about debugging your Heroku application using
> 'heroku logs'
>
> Daniel Myasnikov
>
> On Jun 18, 11:43 am, Karl  wrote:
>
>
>
>
>
>
>
> > Using Rails 3.0.9 (3.0.7 too), which load rake 0.9.2 with bamboo-
> > mri-1.9.2, causes:
>
> > $ heroku rake db:migrate
> > rake aborted!
> > uninitialized constant Rake::DSL
> > /app/.bundle/gems/ruby/1.9.1/gems/rake-0.9.2/lib/rake/tasklib.rb:8:in
> > `'
> > /app/.bundle/gems/ruby/1.9.1/gems/rake-0.9.2/lib/rake/tasklib.rb:6:in
> > `'
> > /app/.bundle/gems/ruby/1.9.1/gems/rake-0.9.2/lib/rake/tasklib.rb:3:in
> > `'
> > /app/.bundle/gems/ruby/1.9.1/gems/rdoc-3.6.1/lib/rdoc/task.rb:37:in
> > `'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks/
> > documentation.rake:2:in `'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:
> > 15:in `block in '
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:
> > 6:in `each'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:
> > 6:in `'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/
> > application.rb:215:in `initialize_tasks'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/
> > application.rb:139:in `load_tasks'
> > /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/
> > application.rb:77:in `method_missing'
> > /app/Rakefile:7:in `'
> > /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2373:in `load'
> > /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2373:in `raw_load_rakefile'
> > /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2007:in `block in load_rakefile'
> > /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2058:in
> > `standard_exception_handling'
> > /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2006:in `load_rakefile'
> > /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:1991:in `run'
> > /usr/ruby1.9.2/bin/rake:31:in `'
> > (in /app)
>
> > I had to add, before require 'rake':
>
> > # Rakefile
> > require 'rake/dsl_definition'
>
> > But I don't get this on my development machine. Why?

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

Re: workers crashing....

[Alex Chaffee]

Try

heroku workers 0; heroku workers 1

to force a worker restart.

btw I upgraded to the 1.9 stack and haven't had a worker crash since.

Alex

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to her...@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

Re: workers dying overnight

[Alex Chaffee]

Update: I upgraded my stack to Ruby 1.9.1 and the crashes seem to have
stopped. (Knock wood!)

  heroku stack:migrate bamboo-mri-1.9.1



On Jul 30, 10:28 am, Alex Chaffee  wrote:
> What a useful command! Thanks.
>
> Still, I don't know what I could be doing to cause DJ to crash.
> Doesn't it catch all exceptions raised by jobs? My jobs are just doing
> plain vanilla Ruby stuff...
>
>  - A
>
> On Jul 29, 8:22 am, Dan Croak  wrote:
>
>
>
> > Only time I've had issues with workers is when I messed up something
> > on my side so that I was causing DJ to crash. I debugged it by doing:
>
> > heroku ps
>
> > On Thu, Jul 29, 2010 at 11:10 AM, Alex Chaffee  wrote:
> > > I wrote a simple Heroku app to do service monitoring. It uses
> > > DelayedJob to queue up repeating tasks like doing an HTTP ping of a
> > > server once a minute or once an hour.
>
> > > Twice now the worker has died overnight. "heroku workers" still says
> > > I'm running 1 worker, but there's no message in "heroku logs" -- not
> > > even the stub of logs from the DJ worker that was there before. It
> > > looks like the worker instance has been retired by the scheduler. If
> > > I run "heroku workers 0; heroku workers 1" then it comes back and my
> > > jobs all start running.
>
> > > Aha! It just started up a worker on its own after I hit the web page
> > > for the first time today. I think the scheduler needs to be smarter
> > > about worker proceses... maybe it needs to check the database for any
> > > Delayed Jobs whose run_at is soon, and either not retire it or make
> > > sure a worker comes online in time to run it.
>
> > > The code is athttp://github.com/alexch/sentryifyou want to try it 
> > > yourself.
>
> > > Has anyone else had this problem?
>
> > > --
>
> > > Alex Chaffee - a...@cohuman.com -http://alexch.github.com
> > > Stalk me:http://friendfeed.com/alexch|http://twitter.com/alexch|
> > >http://alexch.tumblr.com
>
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "Heroku" group.
> > > To post to this group, send email to her...@googlegroups.com.
> > > To unsubscribe from this group, send email to 
> > > heroku+unsubscr...@googlegroups.com.
> > > For more options, visit this group 
> > > athttp://groups.google.com/group/heroku?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to her...@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

Re: workers dying overnight

[Alex Chaffee]

What a useful command! Thanks.

Still, I don't know what I could be doing to cause DJ to crash.
Doesn't it catch all exceptions raised by jobs? My jobs are just doing
plain vanilla Ruby stuff...

 - A

On Jul 29, 8:22 am, Dan Croak  wrote:
> Only time I've had issues with workers is when I messed up something
> on my side so that I was causing DJ to crash. I debugged it by doing:
>
> heroku ps
>
>
>
> On Thu, Jul 29, 2010 at 11:10 AM, Alex Chaffee  wrote:
> > I wrote a simple Heroku app to do service monitoring. It uses
> > DelayedJob to queue up repeating tasks like doing an HTTP ping of a
> > server once a minute or once an hour.
>
> > Twice now the worker has died overnight. "heroku workers" still says
> > I'm running 1 worker, but there's no message in "heroku logs" -- not
> > even the stub of logs from the DJ worker that was there before. It
> > looks like the worker instance has been retired by the scheduler. If
> > I run "heroku workers 0; heroku workers 1" then it comes back and my
> > jobs all start running.
>
> > Aha! It just started up a worker on its own after I hit the web page
> > for the first time today. I think the scheduler needs to be smarter
> > about worker proceses... maybe it needs to check the database for any
> > Delayed Jobs whose run_at is soon, and either not retire it or make
> > sure a worker comes online in time to run it.
>
> > The code is athttp://github.com/alexch/sentryif you want to try it yourself.
>
> > Has anyone else had this problem?
>
> > --
>
> > Alex Chaffee - a...@cohuman.com -http://alexch.github.com
> > Stalk me:http://friendfeed.com/alexch|http://twitter.com/alexch|
> >http://alexch.tumblr.com
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Heroku" group.
> > To post to this group, send email to her...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > heroku+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/heroku?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to her...@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

workers dying overnight

[Alex Chaffee]

I wrote a simple Heroku app to do service monitoring. It uses
DelayedJob to queue up repeating tasks like doing an HTTP ping of a
server once a minute or once an hour.

Twice now the worker has died overnight. "heroku workers" still says
I'm running 1 worker, but there's no message in "heroku logs" -- not
even the stub of logs from the DJ worker that was there before. It
looks like the worker instance has been retired by the scheduler. If
I run "heroku workers 0; heroku workers 1" then it comes back and my
jobs all start running.

Aha! It just started up a worker on its own after I hit the web page
for the first time today. I think the scheduler needs to be smarter
about worker proceses... maybe it needs to check the database for any
Delayed Jobs whose run_at is soon, and either not retire it or make
sure a worker comes online in time to run it.

The code is at http://github.com/alexch/sentry if you want to try it yourself.

Has anyone else had this problem?

--

Alex Chaffee - a...@cohuman.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to her...@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

Re: alternative to pony

[Alex Chaffee]

Check out the Mail gem, the successor to TMail.

Also, if pony's a gem, you can declare it in .gems and it'll add 0MB
to your slug size. Same with mail.


On Jul 8, 1:27 pm, Shane  wrote:
> I just added pony to my app to send email and it added ~1.5MB to my
> slug size. Is there an alternative that's lighter?
>
> Thanks,
> Shane

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to her...@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

Re: Deployment Planning and general safeguards

[Alex Chaffee]

We've got our own set of rake tasks which I recently extracted into a
separate object so I could add tests and make them more modular. They
add a few features to the (awesome, stellar, beautiful) heroku deploy
process:

* "rake stage" pushes master to staging
* "rake deploy" pushes what's on staging to production, even if you've
done more work on master
* deploy (to staging or prod) sends email to a given list saying
what's changed since the last production deploy
* generates and deploys a "/version.txt" file with current git hash
and database migration version so you can verify what version is on
what server
* generalizable to other non-production apps (e.g. we use a separate
site for user testing)
* "rake stage_db" pulls the production DB locally then pushes it to
staging

There's still some proprietary stuff in there but with enough pressure
I could probably find the time to package it up on github...

I like Arron's idea of grabbing a bundle on every deploy too. We used
to grab the DB on every deploy (also "just in case") but the DB is too
big now for that to be feasible.

 - Alex


On Jun 25, 6:47 am, johnb  wrote:
> Arron,
>
> Could you share those rake tasks? Be interested in checking them out
>
> cheers,
>
> john
>
> On Jun 23, 5:58 am, Arron Washington  wrote:
>
>
>
> > Nobody?
>
> > OK, I'll share what I do. :3
>
> > For an important project hosted on Heroku (that I don't want to go
> > down), I tend to wrap everything up in rake tasks that handle
> > deployment, caching assets on Amazon S3/Cloudfront, etc. As part of
> > these tasks, I also include the ability to roll back to a previous (or
> > arbitrary) Git commit. I use the 'git' gem to handle these commands
> > internally, and since there's always an official repo that isn't
> > hosted by Heroku, it's safe to nuke the Heroku repositories using the
> > '--force' flag when required. Once the tasks are developed and the app
> > is live, nobody is allowed to do a raw `git push` to the Heroku
> > remotes anymore.
>
> > We keep our environments/staging.rb as close to our environments/
> > production.rb as possible.
>
> > Deploy tasks also capture a Heroku bundle for each deploy, but I think
> > the Heroku bundles also take a snapshot of the database -- data is
> > generally not something we're willing to use during an emergency
> > recovery, so we don't use the bundles. They're there just in case.
>
> > On Jun 18, 7:49 pm, Neil Middleton  wrote:
>
> > > Following on partly from my earlier email about support:
>
> > > We have an app that we've deployed a production and staging environment 
> > > for.
> > >  The idea being that all deployments go via staging prior to production 
> > > as a
> > > way of testing that Heroku is happy to spin up and 'accept' our 
> > > application
> > > (config is nearly always the issue).
>
> > > Question is, what steps do people do to prevent themselves from ending up
> > > with a production app that's failing to start?  I know some users are
> > > pushing a large amount of traffic where downtime is unacceptable, so what 
> > > do
> > > you do to protect yourself?  How do you recover if things go bad?
>
> > > For anyone to trust something as different as Heroku, I think you have to
> > > know how to get back to a working state asap without outside intervention
> > > where possible.

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to her...@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

Re: Web Stats

[Alex Chaffee]

Google Analytics is indeed the best (if not the only) way, in my
experience. We also log some significant events (e.g. signups) in our
database as they happen, and provide a protected "/stats" page for
admins.

On May 28, 10:50 am, DAZ  wrote:
> Hi,
>
> Is it possible to get basic web stats such as page hits about sites
> that are hosted on Heroku? If not, is the easiest way to use Google
> Analytics or something similar?
>
> cheers,
>
> DAZ

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to her...@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

Maximum RAM per dyno?

[Alex Chaffee]

I've got some frequently-accessed data I'd like to store in RAM
between requests. I'm using Sinatra so I'll probably just use an LRU
cache in a @@class variable. I think I can muddle through all the
technical issues but one:

How big can I reasonably make my cache? I.e. how high (or low) should
I put my threshold before I start expiring unused data?

The only guidance I could find from a quick perusal of heroku.com was
on http://legal.heroku.com/aup: "Dyno RAM usage: 300MB - Hard" --
which is good to know, but not a complete answer. I'll obviously want
to set my cache well below that limit. But without monitoring tools I
don't have any idea how much RAM is used by the normal processing of
Rack + Sinatra per request, nor do I know how many requests are being
serviced per second. My cache is supposed to increase performance, not
decrease it by hammering the dyno into swap space, or otherwise
interfering with other system functions on the dyno.

So... any ideas? Has anyone else done this? Are there any low-level
monitoring tools I can use to find out how much RAM I'm currently
using, or how loaded the system is, or anything of that nature? Would
New Relic help here (and does it work for Sinatra apps)?

BTW, although I may want to use memcached as an *additional* caching
layer, what I'm interested in exploring now is the feasibility of
storing transient data in the app server itself. (I don't want the
overhead of instantiating Ruby objects, especially ActiveRecord
objects, not to mention that memcached isn't officially available as
an addon.)

---
Alex Chaffee - a...@cohuman.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to her...@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

problem (and solution) with migrating db twice

[Alex Chaffee]

I've set up two Heroku instances, one for production and one for
staging. When I deploy to staging I copy the production database over
(using "heroku db:pull" followed by "heroku db:push --app
cohuman-staging") and run all migrations (using "heroku rake
db:migrate --app cohuman-staging"). So far so good.

Sometimes we don't want to push to production right away; we need to
fix bugs or whatever on staging. But then we have to deploy to staging
again.

Here comes the problem: since I copy the production database again, I
need to run migrations again. But if one of those migrations renames a
table, I get a Postgres error:

/usr/local/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract_adapter.rb:219:in
`log': An error has occurred, this and all later migrations canceled:
(StandardError)

PGError: ERROR:  relation "followings" already exists
: ALTER TABLE "interests" RENAME TO "followings"

Apparently "heroku db:push" doesn't clear out the database first, so
the old new table (if that makes sense) is still around.

My solution was to add the following in my "rename" migration:

  def self.up
execute "DROP TABLE IF EXISTS followings"
rename_table :interests, :followings
  end

It's kind of annoying, partly since this code is only necessary on
staging, so it's needlessly complicating things when run on
production...

I'd be interested to hear if anyone has any cleaner solutions. For
example, if I start using Heroku Bundles for backup, can I restore
from my production backup to my staging database? (I admit I haven't
used bundles yet and am sketchy on the details so feel free to RTFM
me.)

 - Alex

P.S. I've got a relatively clean rakefile for wrapping deploys to
Heroku with things like grepping git logs and sending an email; let me
know if anyone's interested and I'll post it in a gist or something.

---
Alex Chaffee - a...@cohuman.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to her...@googlegroups.com.
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

UTC vs Ruby, ActiveRecord, Sinatra, Heroku and Postgres

[Alex Chaffee]

Here's a blog article I just wrote which may be relevant to the Sinatra and
Heroku communities. I've pasted the HTML into this email for your perusal,
or you can read it and check other comments at

http://pivotallabs.com/users/alex/blog/articles/1142-utc-vs-ruby-activerecord-sinatra-heroku-and-postgres

---
Alex Chaffee - a...@cohuman.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com


 Now that I'm starting to use DelayedJob to perform jobs in the future in my
Heroku Sinatra app, its important that they happen at the scheduled time.
But unless you pay attention, you'll find that times get mysteriously
changed -- in my case, since I'm in San Francisco in the wintertime, by +/-8
hours -- which means that some conversion to or from UTC is being attempted,
but it's only working halfway.

Trying to keep a handle on which libraries are attempting, and which are
failing, to convert times is a losing battle, so I'm trying to do the right
thing and save all my times in the database in UTC, and convert them to and
from the user's local time as close to the UI as possible. Unfortunately, a
variety of gotchas in Ruby and ActiveRecord and PostgreSQL makes this
trickier than it should be. Here's a little catalog of my workarounds.
--

You must set both Time.zone = "UTC" and ActiveRecord::Base.default_timezone
= :utc. Since I'm using Sinatra, not Rails, this stuff goes either in
main (i.e.
not inside any class) right after require 'active_record', or in a
configure block
in your app, depending on your preference.
--

When ActiveRecord creates queries -- which are used for both reading
*and* writing,
mind you -- it will only convert to UTC times that are instances of
ActiveSupport's proprietaryTimeWithZone class. It will *not* convert regular
Ruby Time objects, even though Time objects are perfectly aware of their
time zones, and AR is perfectly aware that you'd prefer they be written as
UTC (due to the default_timezone setting). This is clearly a bug IMHO, but
the Rails core marked the bug as "will not fix", so w/e. Here's a monkey
patch, courtesy of Peter Marklund <http://marklunds.com/articles/one/402>:

  module ActiveRecord
module ConnectionAdapters # :nodoc:
  module Quoting
# Convert dates and times to UTC so that the following two
will be equivalent:
# Event.all(:conditions => ["start_time > ?", Time.zone.now])
# Event.all(:conditions => ["start_time > ?", Time.now])
def quoted_date(value)
  value.respond_to?(:utc) ? value.utc.to_s(:db) : value.to_s(:db)
end
  end
end
  end

--

When outputting timestamps to a UI -- either inside HTML or in a JSON API --
you'll probably want to use Time#strftime. Beware: on Mac OS X under Ruby
1.8, the %z (lowercase Z) selector will emit the *local time zone*, not the
zone of the Time object you've called strftime on. The solution is to either
use %Z (capital Z) or just a plain Z which stands for Zulu Time. The latter
is OK if you know you're using UTC, which, if you've followed my advice, you
probably do. This is a pretty annoying issue, since it's much safer to use
%z's hour offsets than %Z's three-letter codes, since the three-letter codes
can be ambiguous, and in any case require an extra conversion to time
offset, so you may as well just emit the offset.

Here are some methods on Time you may want to use that work around this %z
 issue:

  # Note: do NOT call this file 'time.rb' :-D

  require 'time'

  class Time
def full_date_and_time
  strftime('%Y-%m-%d %H:%M:%S %Z')
end

def iso8601
  strftime('%Y-%m-%dT%H:%M:%SZ') # the final "Z" means "Zulu time"
which is ok since we're now doing all times in UTC
end
  end

That iso8601 method comes in really handy when you're using the
excellent timeago
jQuery plugin <http://github.com/rmm5t/jquery-timeago> by Ryan McGeary
(@rmm5t).
--

By default PostgreSQL saves timestamps *sans* time zone, which means that
ActiveRecord interprets them as being in the default_timezone. If you want
to be extra clear and save them*with* time zone, you'll have to change the
Postgres adapter's type mapping. ActiveRecord doesn't let you configure this
but here's a monkey patch, courtesy of Chirag
Patel<http://jacqueschirag.wordpress.com/2007/08/13/timestamp-support-rails-and-mysqlpostgresqloracle/>
(with
a couple of mods):

require 'active_record/connection_adapters/postgresql_adapter'
class ActiveRecord::ConnectionAdapters::PostgreSQLAdapter <
ActiveRecord::ConnectionAdapters::AbstractAdapter
  

Re: Site down between Push and Migrate?

[Alex Chaffee]

Awesome. That's even better than I'd hoped! :-)

 - A

On Aug 17, 12:00 pm, Adam Wiggins  wrote:
> On Sun, Aug 16, 2009 at 10:39 AM, Alex Chaffee wrote:
> > During the few seconds the restart is happening, what happens to
> > incoming HTTP requests? Are they queued or do they fail? If the
> > latter, where's the error page and can we change it?
>
> > And what's the timing like for applying the change to multiple dynos?
> > Is it possible that one dyno is still running the old code while
> > another is running the new code?
>
> Requests will always be going to one and only one revision of the code
> at a time.  The sequence is like this:
>
> 1. You git push, which compiles a slug.
>
> 2. If successful, the slug is distributed to our dyno grid and dynos
> are started for the new slug.  But no traffic is being sent to them
> yet - the routing mesh is routing all traffic to the dynos running the
> old slug.
>
> 3. Once all the new dynos are up and ready to receive connections, the
> routing mesh updates its routing table.  Existing requests will
> complete on the old dynos, any new requests will be sent to the new
> ones.
>
> In summary, the switch is instantaneous and seamless, with no period
> of error pages or requests being routed to the wrong dyno.
>
> You can test this yourself by running a simple load test during a
> deploy.  Something like:
>
> $ ab -c 1 -n 50http://myapp.heroku.com/| egrep '^(Complete|Failed)' &
> $ git push heroku
>
> When I ran this I got the following output (after all the git push /
> heroku slug compile messages):
>
> Complete requests:      50
> Failed requests:        0
>
> Adam
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to heroku@googlegroups.com
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en
-~--~~~~--~~--~--~---

Re: Site down between Push and Migrate?

[Alex Chaffee]

Ricardo -

Thanks for the detailed replies but I'm still unclear on a few things
about downtime during deploy.

During the few seconds the restart is happening, what happens to
incoming HTTP requests? Are they queued or do they fail? If the
latter, where's the error page and can we change it?

And what's the timing like for applying the change to multiple dynos?
Is it possible that one dyno is still running the old code while
another is running the new code?

 - Alex

On Aug 13, 10:48 am, "Ricardo Chimal, Jr."  wrote:
> running migrations before updating the code would still leave you in a
> similar broken state because the database schema has changed but your
> code has not been updated for it.  Depending on how much has changed
> will be the severity of your "brokenness".  Keep in mind that this is
> still a small period of time we're talking about, seconds not minutes.
>
> We used to have it automatically call rake db:migrate but there are
> problems when the migrations themselves were broken.
>
> On Aug 13, 5:14 am, Chap  wrote:
>
>
>
> > Good point Richard, if we have to handle it ourselves I think it
> > deserves a little mention in the docs.
>
> > I assume that most people are use to capistrano which had a "cap
> > deploy:migrations" command that would run the migrations before
> > symlinking the new code. (Although I never personally tested it.)
>
> > Maybe heroku needs needs a similar command that would run the
> > migrations before updating the code?
>
> > On Aug 12, 3:22 pm, "Ricardo Chimal, Jr."  wrote:
>
> > > This is going to be a problem wherever you deploy your application
> > > to.  And what "happens" during that gap is really up to you.
>
> > > Once the push completes the old version of your codebase is no longer
> > > running.  If the migration changes the database schema radically odds
> > > are you're going to see a lot of broken pages because presumably you
> > > have updated your code for those changes.  If the migration does
> > > something minor, then you probably won't see a lot of breaking.  The
> > > point being that handling this is left to you as the developer to
> > > handle.
>
> > > One option is to have a maintenance flag in your database or config
> > > var that you can toggle to display a maintenance page.  This is
> > > probably the easiest to do and could be used for a large set of use
> > > cases.
>
> > > Another option would be to have code that can work around your schema
> > > changes, this is probably the most difficult for most to implement but
> > > it is an option.
>
> > > --
> > > Ricardo
>
> > > On Aug 10, 5:40 am, Chap  wrote:
>
> > > > Between the push to heroku (which will automatically launch the app)
> > > > and heroku rake db:migrate what happens?
>
> > > > I know it's only a few seconds, but potentially the site would be
> > > > broke right?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to heroku@googlegroups.com
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en
-~--~~~~--~~--~--~---

Re: .gems vs. geminstaller.yml

[Alex Chaffee]

> Is there a feature that Gem Installer offers that you wished you had
> for the gems manifest?  

Not yet... But I want to be able to have a single config file, not 2
or 3. Since geminstaller has nice features like rogue gem listing
which may come in handy, I'd prefer that one.

> Or are you looking for
> standardization/interoperability with an existing community tool?

Basically that, plus I'm friends with Chad so I want to represent.

But it's not a huge deal.

 - A

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to heroku@googlegroups.com
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en
-~--~~~~--~~--~--~---

.gems vs. geminstaller.yml

[Alex Chaffee]

Geminstaller has been out for a while now and has many good features
and a YAML config file and a trivial activation sequence. Any chance
Heroku can look for geminstaller.yml in addition to (or instead of)
the .gems file?

http://geminstaller.rubyforge.org/

 - A

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to heroku@googlegroups.com
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en
-~--~~~~--~~--~--~---

Re: Spam

[Alex Chaffee]

Please keep the Google Group. Every web-based forum is missing some
feature that email has that is vitally important to some people and
irrelevant or invisible to others (usually it's the latter type who
advocate moving to a web-based system, imagining everyone else will
follow them there because of some whiz-bang feature that's caught
their fancy).

The most important feature for me is the ability for replies and new
messages to show up in my inbox. If something requires me to visit
some web site, or, Lord help me, register for yet another account in
order to post a message, then it may as well not exist. And even if I
do muster the abnormal motivation to follow a discussion into the
wasteland, I am continually assaulted by misfeatures like hierarchical
threading, animated avatars, spastic layouts and color schemes, broken
search...

Google Groups have searching, archiving, moderation, etc. etc. etc. I
understand the need for a more featureful ticket system but please
please please keep discussions in a mailing list where they belong.

 - A

On Jun 24, 4:27 pm, Morten Bagai  wrote:
> Hey there,
>
> I made that settings change for the group, and also nuked some of  
> recent spam. Sorry about the inconvenience. On a related note, we're  
> very interested in how we can make the support/community experience  
> better for you guys.
>
> One of the actions I'm considering is moving the Heroku discussion  
> forum to our Zendesk support system at support.heroku.com. It has a  
> decent forums feature, which you can check out 
> here:http://support.heroku.com/forums/51588/entries
> . If you have any feedback on that I'd love to hear about it.
>
> Best,
>
> Morten
>
> On Jun 24, 2009, at 8:18 AM, ladyfox14 wrote:
>
>
>
>
>
> > I second that.
>
> > It would also be nice if groups.google.com had a spam button that
> > could only be used for registered users.
>
> > Or is it possible for heroku to set up a forum on their main page?
>
> > On Jun 23, 9:12 am, Trevor Turk  wrote:
> >> I've read elsewhere that setting the "first post by a user must be
> >> approved by a moderator" thingy in Google Groups can really help with
> >> spam...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to heroku@googlegroups.com
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en
-~--~~~~--~~--~--~---

Re: Way to see DB size used?

[Alex Chaffee]

Doesn't work. All I get are url, git repo, and collaborators. No size
info.

On Jun 3, 4:50 pm, Adam Wiggins  wrote:
> On Wed, Jun 3, 2009 at 4:44 PM, Carl  wrote:
> > Is there anyway to see the size of the database being used on Heroku,
>
> http://docs.heroku.com/heroku-command#app-commands
>
> Adam
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to heroku@googlegroups.com
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en
-~--~~~~--~~--~--~---

Re: Getting Heroku errors...any updates/suggestions?

[Alex Chaffee]

I agree with Jason on all counts.

I wasn't even following their twitter feed and it didn't occur to me
to look there -- I still think of Twitter as a channel for superficial
gossip, not mission-critical support alerts. And considering
*Twitter's* notorious issues with downtime, I think it's a dangerous
precedent for Heroku not to post to other channels -- like perhaps
this Google Group, not to mention their own web site -- when things go
South.

 - A

On May 16, 11:23 am, Jason McCay  wrote:
> Heroku looks to be back up...but for our app, we were unreliable since
> 7PM CST last night (first report of customer issues) and it seemed
> like we were completely down from at least 7AM CST this morning until
> around 1:00 PM CST today.  So, a couple of observations:
>
> 1. That was a long period of being down.
>
> 2. The Heroku team really has to do a better job of communicating with
> people when something like this happens.  I attempted to find updates
> through multiple channels (twitter, blogs, irc, and finally this
> google group) and Heroku had said nothing.  Then, after about five
> hours of being down, they finally start responding on twitter.
>
> I love you Heroku...but I have to be able to trust you, too.  :)
>
> Jason
>
> On May 16, 12:36 pm, Alex Chaffee  wrote:
>
>
>
> > A further report... as of 10:30 am my server is totally unavailable as
> > well.
>
> > "heroku logs" returns a blank line.
>
> > "heroku db:pull" returns "Internal server error"
>
> > Hitting the web site gives the ouchie Japanese guy.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to heroku@googlegroups.com
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en
-~--~~~~--~~--~--~---

Re: Getting Heroku errors...any updates/suggestions?

[Alex Chaffee]

A further report... as of 10:30 am my server is totally unavailable as
well.

"heroku logs" returns a blank line.

"heroku db:pull" returns "Internal server error"

Hitting the web site gives the ouchie Japanese guy.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to heroku@googlegroups.com
To unsubscribe from this group, send email to 
heroku+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en
-~--~~~~--~~--~--~---