Newbie here! Have been watching videos on how to create web apps. using Ruby on Rails and cloud9 as the development environment. My training assignment is to create a saas app. This app has a contact form that visitors can use to enter their comments and contact info. The goal is to set up an automatic email that will let me know when someone submits their contact info on the website. When I got to the point of the training that transfers my code to the production environment (Heroku) I set up Mail Gun, but when I test the form out and hit submit button, it says that an error occurred and I should check the logs for more details. I have checked my code and can't find anything wrong. Hoping someone has run into a similar problem and can offer suggestions.
I have created a super simple rails app that takes a list of products, creates product records for each, hits a third-party API using the product ID and accordingly populates the respective product data from the response into each product record in the app.
It's perfectly fine locally with a list of up to a dozen products or more, all on the fly at run-time, so to speak. Images and all.
Additionally, I have added logging to show when the API call takes place and logs the raw XML response. Works fine locally.
I deploy to heroku and searching any ID, it breaks. The app throws what appears to be a 500 ("something went wrong") only to see later that the respective product objects have actually been created, though no product data was populated, nor was the API call ever made. (Literally, there is nothing logged, error or otherwise.)
Best practices aside, what I'm wondering is whether all third-party API calls on heroku need to be made from background jobs, or perhaps whether there's something else I'm missing.
I have implemented activejob too but still getting the same results. What could it be?
Thanks for your help.
All I needed to do was set my env variables with figaro.
$ figaro heroku:set -e production
Derp.
Thanks #Casper :)
So logging in to my site has suddenly stopped working... I haven't changed the login form and yet every time I try to log in now it comes back with 'Invalid email or password'. Using a password reset link allows me to change the password and logs me in but if I log out again and try using the password I just set it doesn't work.
I'm absolutely tearing my hair out, I've run out of ideas and it's 2am here so everything's looking pretty bleak. Just some ideas about how I might debug the problem would be great.
Thanks!
So, as is often the case, this was just me being an idiot. Note to self: don't just casually run bundle update without thinking about it and without specifying the actual gem you're interested in, unless you've got a lot of free time and a plentiful supply of Prozac.
When I do get around to deliberately upgrading Devise, this is what I'll need: https://github.com/plataformatec/devise/wiki/How-To:-Upgrade-to-Devise-2.0
It's great working from home, riding solo on projects, but I do miss being part of a team - just having someone to talk to about issues that crop up really helps and keeps you out of a mental rut. StackOverflow is my team now, you lucky people, I'll make the coffees.
If the password is correct and you can't login then it points to maybe your password salt or password pepper logic having changed?
In the future, you should have a request test on you signup form so you can catch this when your code changes. Writing a test might help you debug your issue as well. I recommend Capybara for integration testing.
I have a batch invite command where users can enter a bunch of emails to invite people to an account in my app. However, up until now, it was including one space at the front of every e-mail...
I've since added a .strip for every new email, but I now want to update all previously created accounts.
I am running the app on heroku, so I'd imagine it will be a command at the heroku console, I just don't want to feck it up, so I'm asking for help here.
Nevermind, I figured it out.
User.all.each do |user|; user.update_attributes(:email => user.email.split); end
That was the solution. Just a little tricky figuring out that Heroku only works with one line at a time, unlike the actual rails console.
If you can execute SQL via the rails console. Try
begin; update users set email = trim(email); commit;
It's quite common in sites- you have a "demo" version with a guest account full of data/posts/comments that you can play with, and all the data is reset every few hours so users wont spam the demo site.
I thought to have another rails environment, "mysite_demo" and use a cron job to call rake to reset it's database every X hours, and populate the seed data.
Then it hit me that all over my app I'll have to check if I'm running in "demo-mode":
For example, if the demo site has a login/register page too, a user might register, insert some data and wonder why his account is deleted after he logged in again.. so demosite shouldn't have a register option at all.
So I thought I'll make a "demo" branch of the code.. with the difference and just merge changes as I go... sounds like an overkill.
ideas?
In my application I started with a fixed demo user with an account that resets every hour. Something about that model didn't quite sit right - if there were multiple users hitting the demo at the same time you could get into some weird concurrency issues. And what if a user is in the middle of a demo and your reset the demo account? What happens?
I don't know if this model works for you but I ended up creating a brand new user account with a demo flag set in the database - I also automatically log the user in. This way the user gets to play around for as long as they like and I don't have to worry about data getting deleted/changed while a user demos my app. I run a cron job every night that deletes users with the demo flag set that are older than 24 hours.
If the demo version is running from its own database, how is it any different from the real thing? The demo site is just an instance of your product.
Just clean up the DB and redeploy the demo as needed. Is it just this simple or am I missing something?
Then it hit me that all over my app I'll have to check if I'm running in "demo-mode" (e.g, you cant register a new user in the demo) and make the site behave accordingly.
If the site is in demo, why does it matter what the users do? Anything they do will be wiped in a few hours, so they won't be able to actually do work with it.
It sounds like you are trying to handicap the site so they will pay. I don't know what your site does, but if its a host based service(web page that stores & display information) then the limited life span of the data should deter squatters.
If you website does something that can be used elsewhere, then I can see limiting it. An example might be a service that transforms media formats, or writes resumes. If the user can do something useful in the 2 hour window and walk away with it, then you might consider branching.
Why not allow the user to make an account even if it is deleted in an hour?
That allows them to see how the registration process of the script works for at least an hour, maybe give a message on the signup page that the account is only valid for an hour.
Just my thoughts
Is there any other functionality that is different in the demo version than the production environment? If it is just an issue of making the user register, you could just create a registered demo account in production, and give out the user name/password for people. Although this may not be an option depending on other business requirements.
If you are willing to use Authlogic you can take a look at this, then every X hours you can look through the database for users that start with anonymous_ and delete records that are associated with them.
Just make a separate demo site that works exactly like the production one, but the DB gets reset once an hour to clean example data. The only change you need to make is a banner across the top of every page that says its a demo. There are several ways to do it, (modify your site theme, or maybe use frames) but basically you should only have to change the code in one place, instead of throughout the site.
You could setup a new environment demo on your database.yml, with read-only privileges for the User table, and an additional demo_database. Then place some checks on your code to see if your RAILS_ENV is on DEMO.
That way, you only need to work with the same codebase and just show whatever you feel like it.
You can deploy it as a separate app with its own database to a separate domain or subdomain and then check the domain to decide what options should be available. For instance if you put it on demo.example.com you would use:
if request.domain =~ /demo/
If you use Capistrano you can set it up to update both apps when you deploy so they are in sync.