Use annyang-node of course.
Use annyang-node of course.
When moving a site from one server/host to another it’s often necessary to have both servers/hosts share a third server’s database. This is necessary because as the DNS change propagates around the world some user’s ISP may send them to your old server and some may arrive at the new server.
If you had two independent servers running two instances of MySQL the records in the database won’t match and some users will never be on the new server. This is especially a problem if you’re running a subscription based website. You merchant may have already processed their account information and confirmed them on your site, but wait, were they confirmed on the old server or the new one?
Using a shared database allows users who sign up to your site through the old server to be added same database as users who sign up through the new server. But MySQL doesn’t allow this to happen by default. It thinks that any incoming request from an outside connection is a security threat.
The internet is usually a great place to find tutorials, especially relating to programming. However, configuring a MySQL database for remote connections seems to be a poorly documented thing online.
With that in mind, here is a short explanation of how to configure MySQL to allow remote connections.
Note: this will not work on shared hosting.
Have you ever wanted to login to your servers via SSH without using a password?
Here is a very short explanation of how to do it.
Since deciding to use WebSockets instead of AJAX calls with Node.js I have discovered some interesting things. Some of these things are good, and some are bad.
Node.js is great at times, but in some ways it’s a real pain in the ass.
Sure, it can create WebSocket servers, and it seems to be on the cutting edge of everything, but try to update an array of objects in a database then output a message and you’re in trouble.
I’m in the process of converting a web application from an Apache + PHP backend to Node.js. The application being converted is based heavily around real time interaction between users, so, it was a natural fit for WebSockets.
In fact the old application used a Node.js backend for WebSockets, but an Apache + PHP backend for everything else, including page generation and AJAX endpoints. This means every AJAX driven form had a PHP endpoint which performed a desired action and a WebSocket event listener waiting to broadcast the event to other users.
Having to recode this application from the ground up in a new asynchronous language presented an interesting question to me.
Why should I use AJAX when I have WebSockets?
One of the biggest hangups I had when starting to program was deciding what technology to use. At the time I was only writing server side code and was working in shared hosting, so my options were limited to various versions of PHP.
Within the last year I started using cloud hosting and thus gained the ability to configure my servers to use any language I wanted. Shortly after realizing this a small amount of fear came over me. The choice of language wasn’t made for me anymore, I would have to pick from a giant pool of languages. I would also be spending at least three months learning all about this language I picked before I would feel secure in it. After that three months I might not like it and would have wasted three months of my life.
At the time I was doing a lot of freelance and was instructor at a college teaching web development. Because I was teaching I wanted to know the basics of all the languages I could use on the server, just in case my students asked me about them.
I knew the basics of most of these languages but I had never written anything substantial in them. So, over one long weekend I locked myself in a room and started writing hello world, testing frameworks, making CRUD, overall building projects in every language and every framework I could get my hands on.
Four days later here are the four things I learned.