Sunday, October 26, 2014

Interactive Programming in Web2py

I've been working on Beth's website over the past few months. I find the easiest way to work through building the logic is to leave the views empty in the controller, and work with the web2py debug view to get the locals(), when this is working, I can move on to the next step. I find I'm making a few temporary lists to hold intermediate results, and inspecting. The web browser is a pretty useful tool for what' essentially printf debugging. I haven't used the other debug tools much, but I think the tickets (unless the model gets so wrong the tickets won't load) are a good way to return to a stack trace, and present both a developer view of open issues, and allow the user to forward a link to the website.

I had initially been working live, which was nerve wracking when the changes would break a migration and take down the site. I think having many controllers is better for small local changes, since broken code in the same file can prevent interpretation. I might have structured this differently if python could ignore some blocks...

I just wish that the wsgi setup on cpanel servers weren't so counter-productive. I currently have a cron to ensure the socket is owned by the site user, since it defaults to root/nobody, and under cpanel's configuration (maybe this is suexec related), the account doesn't have access to the wsgi server.

4 comments:

BadPirate said...

I found that the least nerve wracking way to work on a website is to put it all in a GIT repository, clone it to a second folder / different path, work on it there and when you are happy, push and pull it to production. Gives you roll back and piece of mind.

Dan said...

I actually do the testing and debugging on a separate machine, via mercurial plus a manual database clone from time to time.

This is largely to allow automatic migration of the database without taking the whole site down because something strange happened with the database state.

It also gives me a good feeling that I have a separate install, it avoids from piling in too much untracked shims (there are always a few, unless you keep your webserver conf file in version control, too). From time to time I like to spin up a digital ocean instance to time how long it would take to have the site running on a new host. I can get the setup from basics to running in about an hour, and that's less than the ttl on my dns, so it's probably fine. I think it could take longer to realize there was a problem than it would to fix it.

And from now on, I'll remember that badpirate is my #1 reader/reviewer.

BadPirate said...

#1 of 1! WOOO!

Also, I miss you man. Seriously, you're like one of only a few people I know who spin up web servers and attempt to do backup restoration just to see how long it takes.

Dan said...

Well, I have a lot of clients who make backups, or think they do, or meant to, and don't actually have any clue whether they're complete, or usable, or how they'd need to use them. They also then leave the backup files on the server they are backing up, which is an exercise in pain. Akin to keeping your wad of civilization-came-to-an-end-and-I-need-to-bribe-my-way-out-of-this cash in the bank, thinking you'll just go to the atm when the revolution comes.

More importanyly, I miss you, too. If you ever lose your mind and find your way out this far east, you're encouraged to find me here in Chicago. We might head to California later in the winter, but probably farther south. Maybe as far north as San Luis Obispo, but probably not going to San Jose unless we fly through there. In the plan we don't have on how this might work, we see ourselves flying to San Diego, and maybe renting a car to drive up to the central coast.

I heard you got married -- Congratulations. I hope your fruit salad tree is also flourishing.