Thanks, that's a big help. Is there any way to foolproof in git? In SVN unless you get rid of the repository on the server directly (which most users don't have access to), everything is saved so work isn't lost (as long as you check in). According to point number 7 on: http://steveko.wordpress.com/2012/02/24/10-things-i-hate-abo...
a user can potentially blow everything away with no clear way to recover, is this something to be concerned about or can failsafes be easily built in so this doesn't happen?
You can set up a script that will auto push to a remote repo on commit, the confusion comes in with the terminology in most distributed systems commit just means tell my local source control to track the change, where as in the centralized model commit generally means move these changes to the server. Just remind them that nothing gets to the server without a push. distributed systems have serious advantages over the centralized model, specifically when it comes to getting everybody's changes merged together in a chronological order. That advantage far outweighs the learning curve. If you use Mac's I would recommend SourceTree it is a very good UI for GIT and HG.
Nice. Am I the only one that gets ~7 screen heights of spam for a specific brand benzodiazepine on that page (above the header) though? Also in the title "xxx Without Rx". Wtf?
Using FF7 with Flashblock. It's right there in the page source.
Cool until you click on their "contact us" page, and get a map. Do they think I'm going to fly to Seattle to meet with them, just to contact them? huh.
A word of caution: be very careful using any automated tools to run queries on Google (unless they use the official Google search APIs). For easily understandable reasons, the folks at Google are generally not very happy about such things and this could lead to some harmful consequences for your site if you're found violating their TOS.
Maybe you should change the db structure, to optimize sql queries, use a caching system to delivery static content, or you can ask a more experienced developer to look over db structure and give you ideas. 9000 users don't seem that many to make the server run slow...
Also agree with this. I'd be happy to help you by taking a look and sharing my thoughts on where improvements can be made in the DB structure, configuration, scalability, as well as places where caching will give good results vs implementation costs and effort.
> 9000 users don't seem that many to make the server run slow...
I second that, especially when you have moved mysql on a separate server. I'm sure you're missing something basic here (as happens to many from time to time :-)).
Our server is not slow at the moment. It is pretty responsive. But as 9000 reaches closer to 100000 I am sure existing safe-gaurds will not be enough, so I am asking what else can be done.
