Recently I was using a canned VM that had RedHat EL6 loaded on it, and needed to add a package, only to find that the package had been moved to the RedHat base repository.
Out of the box these images have their timezone set to UTC, and since my end users are in California, and I’m not doing anything on the client to handle timezone conversion, the times that come up in the application are off by 7 or 8 hours (depending on whether it’s Daylight Savings time or not. Continue reading
I was setting up a temporary WordPress site for a client as a placeholder for their business. All they wanted was their logo, a link to an existing product page, and a message about the site being under construction.
I had to set up a WordPress instance on a server where my only real access is via cPanel, so I Googled a bit and found this article: http://www.howtogeek.com/howto/20859/install-wordpress-manually-on-your-website-using-cpanel-wizards/
First step is to log in to the cPanel, which is typically at some arbitrary port on your server, and log in with your admin credentials. If you go to the right URL, you’ll be prompted with something like:
So, just like any WP installation, the first thing you need is a database, so you look for the Database Wizard (in the Databases section):
This will bring up the Wizard which will ask you for a name. In this case I’m creating a test wordpress, so I type in “WP_test” just so I know which DB I’m using. This can really be anything, just has to be unique.
If you’re on a shared host (which I am) this name gets prepended with your admin account name (this is how the server knows which databases belong to you and keeps you from seeing other people’s database schemas).
Going to the next step, you’ll be asked to create the database users. Again this can be anything, but also needs to be unique to the schema you’re creating. At this point the database has been created, but there are no users. The user name also gets prefixed with the account on a shared host system:
You can give the user any name and password you want, you will need those along with the database name once you are ready to fire up WordPress. I believe it is possible to use the same user for multiple databases by skipping this step and manually adding them to the newly minted database later instead, but it’s probably not the most secure way to set up access.
In my particular setup, I want to attach this new WordPress to a specific host name, so the next thing I do is my Subdomains panel in order to create the directory and tell Apache where to send the users. The default behavior is for the directory to be a folder under public_html with the same name as the subdomain, so in my case “WPtest” causes a folder named /public_html/WPtest to be created:
In my case I prefer to keep them separate physically, so I remove the “public_html/” part and call the folder something more meaningful. Depending on your setup, you may also need to add this new host name to DNS, although for testing you don’t even need that (more on this later).
The next thing to do is to get the latest WordPress binary and upload it to the newly created folder, which you can do using the cPanel folder manager:
I next see a popup that asks me where I want the File Manager to start, so I pick my new subdomain:
In reality it displays all of your folders, just starts up opened to that particular one which might save you a click or two. At the top of the file manager, you’ll see the menu bar where you can choose “Upload”:
You’ll get the typical button to choose the file with, and a status bar that will tell you when the upload is complete:
Once it is uploaded, go back to the file manager and with the file selected, click the “Extract” icon, or right click on the file and choose that option:
You can actually choose to extract it somewhere other than where you uploaded it, which could be useful for creating multiple copies or updating WordPress into multiple folders:
Now this ends up creating a wordpress folder under the one where you really want it, so I do a bit of cleanup that involves moving the contents of that folder up one level. I use the File Manager’s drag and drop to move the files, and then delete the empty folders and zip as shown in this video:
After that, the rest of the configuration is a standard WordPress setup through the browser (see: http://codex.wordpress.org/Installing_WordPress#Famous_5-Minute_Install)
Recently after an upgrade of my Plesk panel, my web site was down.
They had it fixed in a moment, and then went the extra step to send me the command to fix this myself in the future:
That simple command reset all the server config files and got all of the domains working again.
A huge thanks to the 1and1 Server Support guys and Khristian Byrd specifically !!!
If you read my previous post (WordPress Recovery), you know I’ve been writing some code to recover my old posts. It occurred to me I could take a small segment of what I’ve been doing with that code to demonstrate my approach to TDD.
Since I’m a hacker from way back, and also because I was in semi-panic mode about losing the content, I didn’t approach this task with testing in mind. Now that doesn’t always result in bad code: I’ve been doing this long enough that I can usually think through a fairly good model and code something that isn’t one long method full of inline code.
In this case however, once I had started coding, I realized again that this was an opportunity to practice coding the “right” way. I had already begun with a Maven project, and generated unit tests as I went through the process of starting to build the code, so I had at least some good functioning unit tests.
Well, I have the basics of my blog recovered now, so almost all of my posts going back several years are once again available.
In my last post titled Lesson Re-learned: Backups !, I admitted that I had committed the cardinal sin of making changes to my web site without doing a backup first (walking the tightrope without a net).
Luckily for me I had installed the WP Super Cache plugin, so all of my content actually still existed as static files, and being a bit of a hacker, I was able to throw together some code to effectively recover my posts.
I just shot my blog in the foot, or more accurately, I didn’t follow IT 101 and back things up before making a change.
I had moved my site to be completely WordPress based a while ago, and as a result I had a bit of a convoluted setup on my server.
When I first set up my WordPress blog it was as a sub-domain of accuweaver.com, and was housed at http://wordpress.accuweaver.com/ (also aliased to http://blog.accuweaver.com/). The http://www.accuweaver.com/ site just static pages that hadn’t changed for years.
So when I finally got my blog set up to host the few static pages I had, I just changed the directory on my server to have a symbolic link to the directory where wordpress.accuweaver.com had it’s content:
This actually worked really well, since the content was only in one place, and all I had to do was change the host name in WordPress. Continue reading
First, if you already have a Google account (like a GMail address), you will want to log out of by clicking on your name or icon up in the upper right corner of any Google app, and then click the “Sign Out” button:
I was reminded a couple of days ago of the danger of using tools that help you to get things up and running quickly, by a question that I was asked in an interview. The question was pretty simple, but not something I’d thought about for a while, which was: “What are the verbs used in RESTful services?”.
Now intuitively I know that answer, but hadn’t really thought about it for a while, so I basically answered incorrectly (mostly because I suck at inteviews), only remembering that you do GET and POST in HTTP, so responding that GET is to query and POST is for inserts/updates.
Of course I know the reality (and one of the advantages) of RESTful services is that they behave by contract, so they can use the full complement of the HTTP verbs, and the convention is to use each one for a specific purpose:
But the last few times I’ve done RESTful services, I’ve simply let an IDE generate them for me, so I haven’t even thought about those last statements. In the IDE, all I had to do was say I wanted to add REST (using Jersey) to my session beans, and voila, I have a full fledged RESTful service.
And of course on the consuming side, all I have to do is call the right method, and under the covers the Jersey client stuff does the right thing about which verb to use. So I’m not actually thinking about what’s under the covers, and because of that wouldn’t be quick on my feet about how the service is constructed under the covers.
There are of course pros and cons to approaching code in this way. In the early days of writing code, we all had to know what the machine language underneath looked like. Modern languages hid that complexity from us, and reading assembly language became a lost art practiced by rocket scientists and performance gurus.
By hiding the complexity we have been able to develop insanely complex applications that would not have been possible without those building blocks. Freeing ourselves with increasingly general patterns in code, we are able to focus on solving the problem at hand, and stand on the shoulders of those that go before us in doing so.
I don’t expect to need to write a RESTful service from scratch any time soon, but it is a good reminder that when you rely on tools to build your code, you are risking living with a lack of understanding of the underlying mechanism, which could make it difficult to know about the pros and cons of a solution.