Re: Automating pgbackups
I've got a lot on my plate right now, but I'm not opposed to getting it into a usable state for other people once I get some spare time. On Nov 17, 2:10 am, Trevor Turk trevort...@gmail.com wrote: On Nov 16, 6:44 pm, Andrew C. andrew.c...@gmail.com wrote: I spin up an EC2 instance from my cron job. The EC2 instance captures and downloads the backup to S3, then shuts itself down. Works well so far. Obviously, it's not free, but it's freaking cheap. Any chance of open-sourcing some of that code? It's an interesting idea. I'm still hoping there's an easier way, but this is certainly an idea! - Trevor -- 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.
Getting InvalidAuthenticityToken errors (without changing anything)
All of a sudden, the login form on my site results in InvalidAuthenticityToken exceptions. This happened without changing any code. The same code base is working fine in my staging app. The only difference between production and staging is the use of the New Relic Custom Domain add-ons. I'm not sure how to fix this. Anyone else encountered it before? Thanks, Andrew -- 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: Getting InvalidAuthenticityToken errors (without changing anything)
Ugh. Lesson learned: Don't cache forms. On Aug 31, 10:36 pm, Andrew C. andrew.c...@gmail.com wrote: All of a sudden, the login form on my site results in InvalidAuthenticityToken exceptions. This happened without changing any code. The same code base is working fine in my staging app. The only difference between production and staging is the use of the New Relic Custom Domain add-ons. I'm not sure how to fix this. Anyone else encountered it before? Thanks, Andrew -- 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.
Caching responses from external APIs
Is there a 'Heroku way' to cache responses from external APIs, like Twitter and Foursquare? I'm using Apigee for Twitter, so the rate limit isn't really an issue, but I need to do something to avoid hitting Foursquare's rate limits. Is it possible to use the existing Varnish instances to cache the API responses? Is MongoDB a better choice? Is there a different option altogether? Thanks, Andrew -- 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: Caching responses from external APIs
that does appear to be an option. I'll try it out. Thanks! On Aug 4, 11:48 am, Neil Middleton neil.middle...@gmail.com wrote: Isn't this what Memcache is for? You just create a key/value pair and lob it into the Memcache server where it stays for as long as it can. http://docs.heroku.com/memcache http://railsapi.com/doc/rails-v2.3.8/classes/ActionController/Caching... N On Wed, Aug 4, 2010 at 7:45 PM, Andrew C. andrew.c...@gmail.com wrote: Is there a 'Heroku way' to cache responses from external APIs, like Twitter and Foursquare? I'm using Apigee for Twitter, so the rate limit isn't really an issue, but I need to do something to avoid hitting Foursquare's rate limits. Is it possible to use the existing Varnish instances to cache the API responses? Is MongoDB a better choice? Is there a different option altogether? Thanks, Andrew -- 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.comheroku%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/heroku?hl=en. -- Neil Middleton -- 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.
access restrictions for collaborators?
Is there any way to limit what actions can be performed by collaborators? I'd like to be able to, for example, allow a collaborator to pull down code, but not push. Or to pull from the database, but not push. Thanks, Andrew -- 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: delayed_job for logging
Hi Agustin, I'm definitely interested. Please sign me up. I'll be launching my app with my current home-brew solution; but once it's up, I'll be happy/eager to explore logworm as a better replacement. Thanks! Andrew On Jul 14, 7:16 pm, schapirama schapir...@gmail.com wrote: Hi Andrew, Logworm is indeed in private beta, but I'll be happy to provision a free account for you separately --I'd in fact appreciate your feedback and comments if you get to use it. You're correct in stating that logworm records the log entries at the end of the request, but that's just an HTTP request from the client application (your app) to our backend system, also running on Heroku and therefore with minimal network latency. Once we receive the log, we do all the processing and inserts into the DB in the background, in order to minimize the total time that the logging adds to your app. In the very near future, our intention is to replace this HTTP call with a faster AMQP call, again to minimize the impact in the response time of your app. BTW, keep in mind that logworm allows you to record any kind of information and not just web requests or exceptions (e.g. audit data, performance information, etc.)... and that it then already gives you tools to retrieve and analyze those data. Our intention is to be the main logging and analytics service for the Heroku platform, so we're working hard on creating a complete, reliable, and efficient solution. Let me know if you're interested and I'll create an account for you. - Agustin -- 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: Programmatically Spinning Workers Up and Down
Hey Pedro, As someone who's still learning uh, Heroku, Rails, Git, Delayed Job . . . how do I go about using this? At the moment I'm using collectiveidea's branch of delayed job, with changes of my own to support Log4r. Should I switch to using your fork of Delayed Job in order to access the autoscale capabilities? I've got the feeling the lack of submodule support makes this tricky too. Could you point me to the best way to incorporate your changes? Thanks, Andrew On Jun 22, 9:56 pm, Pedro Belo pe...@heroku.com wrote: Hi Chris, There is. I made a little proof using DJ that might give you some insight. The code is on this branch:http://github.com/pedro/delayed_job/commits/autoscaling And instructions/notes are on the comments here:http://github.com/pedro/delayed_job/commit/09d7657e1fc7d25072e6c5e73e... On Fri, Jun 18, 2010 at 2:33 AM, Chris Kalaboukis thinkfut...@gmail.com wrote: Hi guys: I saw an old thread on this but there seemed to be no answer. Is there a way within my app to shut down and restart all the workers programmatically? I have a twitter harvesting app which requires it and I need to do it manually. Is there a doc somewhere which describes how to do it? Thanks...chris -- 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.
delayed_job for logging
I'm working on a logging solution for my app. After reading various docs, I got the impression that writing my logs to MongoDB in a delayed job would be a good idea. Just one problem: Delayed Job writes to the logs. 1) Creating a Delayed Job writes to the SQL DB, which writes to the logs. 2) Running the delayed jobs write to the logs. So logging yields more logging yields more logging ad infinitum. Am I totally off the mark by wanting to put log-writes to MongoDB in a delayed job? Is there a way around it? I'm using ActiveRecord::Base.silence when I add the jobs. And passing :quiet = true to the workers. Is that sufficient? Is silencing the delayed jobs a terrible move? Or, alternatively, is it a poor decision to try to replace the RAILS_DEFAULT_LOGGER with my logger? Should I just call my logger directly/redundantly everywhere? Thanks, Andrew -- 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: delayed_job for logging
Hey Steve, Thanks for the response. My reasoning for using background jobs for the writes was to avoid user-experience degradation caused by a slow or unresponsive MongoDB server - which was mentioned as a concern in one of the numerous articles I've read in the last two days. The performance hit in the normal scenario wasn't actually something I was worrying about. Admittedly, I don't know if that tradeoff or those concerns are justified. I haven't yet determined what exactly I'll be logging. I'm pretty new to both Rails and web development in general - so the most straightforward answer is that I don't really know what to log. Bare minimum would be exceptions. General information about requests would probably be good. Beyond that? No idea. Is there a list of 'best practices' somewhere? Should I be logging SQL response times for performance analysis? In addition the Rails logging system was written in a way that it can be replaced I've been using Log4r since I started this. I currently use 3 loggers in my development environment: One that writes all levels to console. One that writes all levels to a file. One that uses a custom formatter and outputter to write anything with severity greater than or equal to WARN to MongoDB in a Delayed Job. Delayed Job writes INFO and DEBUG(via SQL) log entries, so I'm only using the Mongo/DJ combo for log entries above those. This required some minor hacking on how DJ calls the logger, but it's all functional now. (Setting the level to WARN resolved the issue that spawned this post, which was DJ log jobs creating more DJ log jobs). What are people using for logging on Heroku, in general? That'd be something I'd love to know. Heroku recommends Hoptoad and Exceptional for exceptions; do they provide general purpose logging features as well? Does everyone just roll their own logging system? or skip detailed logging altogether? Logworm appears to be in private beta. Details of how it works are here: http://www.logworm.com/faq . The main difference (imo) is that the log data is sent at the end of the request, rather than in the background. Logworm also provides analytics that I'd of course have to create for myself. I'm going to a) move my test-app onto Heroku and verify that it works, and then b) try to move it into my production app. For now it seems sufficient. Thanks, Andrew On Jul 13, 1:03 pm, Steve Smith st...@scsworld.co.uk wrote: Hey, Andrew I am sure there are people far more qualified than me on here that can help however I think it really depends on how much info you are logging. If you are only logging the standard rails requests then I don't see any issues using MongoDB DB without delayed job. Remember as you say delayed job uses a database so it is really for delaying jobs that require a bit of processing. You will possibly find that the delay writing to Mongo Is less than that of the delayed job being stored. I have used MongoDB on MongoHQ for logging user activity on one of our sites before and its a pretty common use case for Mongo to be used for things like this and we were very impressed with the write speeds. In addition the Rails logging system was written in a way that it can be replaced if you need to so that's always an option if its necessary. I've also seen an add-on called LogWorm in the add-ons list I haven't looked into it but would it be of any help to your project? Steve On Jul 13, 9:15 am, Andrew C. andrew.c...@gmail.com wrote: I'm working on a logging solution for my app. After reading various docs, I got the impression that writing my logs to MongoDB in a delayed job would be a good idea. Just one problem: Delayed Job writes to the logs. 1) Creating a Delayed Job writes to the SQL DB, which writes to the logs. 2) Running the delayed jobs write to the logs. So logging yields more logging yields more logging ad infinitum. Am I totally off the mark by wanting to put log-writes to MongoDB in a delayed job? Is there a way around it? I'm using ActiveRecord::Base.silence when I add the jobs. And passing :quiet = true to the workers. Is that sufficient? Is silencing the delayed jobs a terrible move? Or, alternatively, is it a poor decision to try to replace the RAILS_DEFAULT_LOGGER with my logger? Should I just call my logger directly/redundantly everywhere? Thanks, Andrew -- 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.
