Tag Archives: code

How To

Site optimization — the order of your scripts and styles

I watched this video yesterday, where a Googler talks about the importance of ordering your scripts and styles correctly in order to speed up the rendering of your website, made a quick change to my header file, then ran the Page Speed extension for Firefox to see how I was doing. While there still some things to address that could make my site load faster, some of which don’t depend on me but on external JavaScript files from ads and stats and such, I’m glad to see things are a little snappier today.

Google Webmaster Central — Optimizing the order of scripts and styles

There’s extra documentation on this very topic available from Google, in the help files for its Page Speed extension. It’s worth a read, because a quick re-ordering of the code in your site’s header could shave as much as 50% off your site loading times, depending on how much JavaScript you’re using.

Standard
Thoughts

Changed all site URLs

I pushed through some major changes to site URLs tonight. Every single site URL has now changed as a result, but the change is good, and all old URLs should still work just fine, seamlessly redirecting visitors to the new URLs. Just in case though, please let me know if you find a non-working URL.

The changes have to do with how post, category and tag URLs appear. WordPress, my site’s platform, allows me to change URL rewrite rules (the way a certain URL is generated when you visit a page on my site). I’ve wanted to make this change for a long time, and finally bit the bullet after first trying it out on one of my other sites, Dignoscentia.

Here’s what this means for you:

These changes may not be important to some, but they are to me. Once I get something like this in my head, something that I think will help me organize my content a little better and make the URLs a little shorter and easier to type, I have to go through with it.

I have some more changes planned for the actual categories themselves, such as re-organizing my content into more logical categories. I also need to finish tagging all my posts (currently 1242 posts and counting).

This is all part of my long-term efforts to properly curate my content. You may want to have a look at the site news tag to see what other changes I’ve made to the site over time. It’s been an interesting journey with quite a bit of work behind the scenes, but I like doing this sort of stuff a lot.

Standard
Reviews

Google Health is a good thing

When it launched a few weeks ago, Google Health received fairly lackluster reviews. Privacy issues and lack of features were the main complaints. Well, I’m here to tell you those initial views are wrong.

Even if you’re a long-time reader of my site, you may not know what qualifies me to make that statement, so let me tell you a bit about myself.

My background

A few years ago, I was Director of Health Information Systems at a South Florida hospital, where I implemented an electronic medical records system. My job was fairly unique, because I not only wrote the policies and procedures for the system and oversaw its implementation, but I also rolled up my sleeves and built the various screens and forms that made it up. I, along with my staff, also built and maintained the servers and databases that housed it.

As far as my education is concerned, I hold a Master’s Degree in Health Services Administration (basically, hospital administration). I was also admitted to two medical schools. I ended up attending one for almost a year until I realized being a doctor wasn’t for me, and withdrew.

For plenty of years, I’ve been a patient of various doctors and hospitals, as have most, if not all of you, for one reason or another.

Furthermore, my father is a doctor: a psychiatrist. He has a private practice, and also holds a staff job at a hospital. My mother handles his records and files his claims with the insurance companies, using an electronic medical records system. I get to hear plenty of stories about insurance companies, billing ordeals, hospitals and the like.

So you see, I’ve seen what’s involved with medical records and access to said records from pretty much all sides of the equation. Again, I say to you, Google Health is a good thing, and I hope you now find me qualified to make that statement.

The benefit of aggregation

Just why is it such a good thing? Because I wish I could show you your medical records — or rather, their various pieces — but I can’t. That’s because they exist in fragments, on paper and inside computer hard drives, spread around in locked medical records facilities or in your doctors’ offices, all over the place. If you endeavored to assemble your complete medical history, from birth until the present time, I dare say you’d have a very difficult time getting together all of the pieces of paper that make it up — and it might not even be possible. That’s not to mention the cost involved in putting it together.

A few of the problems with healthcare data sharing

Do you know what my doctor’s office charges me per page? 65 cents, plus a 15 cent service fee. For a 32 year old male (that’s me) it would take a lot of pages (provided I could get a hold of all of them) and a lot of money to put my medical record together.

The sad part is that this is MY medical information we’re talking about. It’s information that health services workers obtained from MY body. It’s MY life and MY record, yet I can’t have access to it unless I fill in a special form at every doctor’s office I’ve ever visited, and pay for the privilege. Is that fair? NO. Can something be done about it? YES, and so far, Google Health is the only service I’ve seen that is trying to pull together all of the various pieces that make up my medical record, for my benefit and no one else’s. Sure, the system is in its infancy, and there’s a lot of work to be done to get it up to speed, but that’s not Google’s fault.

I’ve been inside the healthcare system, remember? I know how things work. I know how slowly they work, to put it mildly. I know how much resistance to change is inherent in the system. Just to get medical staff to use an electronic medical records system is still a huge deal. The idea of giving the patient access to the records, even if it involves no effort on the part of the medical staff (but it does, as you’ll see shortly) is yet another big leap.

Let’s also not forget to consider that medical records systems are monsters. Each is built in its own way. There are certain lax standards in place. Certain pieces of information need to be collected on specific forms. The documentation needs to meet certain coding standards as well, or the hospitals or doctors’ offices or pharmacies won’t get reimbursed. There are also certain standards for data sharing between systems, and the newer systems are designed a little better than older ones.

Yet the innards of most medical health systems are ugly, nasty places. If you took the time to look at the tables and field names and views and other such “glamorous” bits inside the databases that store the data, you’d not only find huge variations, but you’d also find that some systems still use archaic, legacy databases that need special software called middleware just so you can take a peek inside them, or form basic data links between them and newer systems. It’s a bewildering patchwork of data, and somehow it all needs to work together to achieve this goal of data sharing.

The government is sort of, kind of, pushing for data sharing. There’s NHIN and the RHIOs. There are people out there who want to see this happen and are working toward it. Unfortunately, they’re bumping up against financial and other barriers every day. Not only are they poorly funded, but most healthcare organizations either do not want or cannot assign more money to either getting good record systems or improving their existing ones to allow data sharing.

Add to this gloriously optimistic mix the lack of educated data management decisions made in various places — you know the kind of decisions that bring in crappy systems that cost lots of money, so now people have to use them just because they were bought — and you have a true mess.

Oh, let’s also not forget HIPAA, the acronym that no one can properly spell out: Health Insurance Portability and Accountability Act. The significant words here are Insurance and Accountability. That’s government-speak for “CYA, health organizations, or else!” There’s not much Portability involved with HIPAA. In most places, HIPAA compliance is reduced to signing a small sticker assigned to a medical records folder, then promptly forgetting that you did so. Your records will still be unavailable to you unless you pay to get them. Portability my foot…

Benefits trump privacy concerns

Alright, so if you haven’t fallen asleep by now, I think you’ve gotten a good overview of what’s out there, and of what’s involved when you want to put together a system like Google Health, whose aim is to pull together all the disparate bits of information that you want to pull together about yourself. Personally, I do not have privacy concerns when it comes to Google Health. There are more interesting things you could find about me by rummaging through my email archives than you could if you went through my health records. If I’m going to trust them with my email, then I have no problems trusting them with my health information, especially if they’re going to help me keep it all together.

Not sure if you’ve used Google Analytics (it’s a stats tool for websites). Not only is it incredibly detailed, but it’s also free, and it makes it incredibly easy to share that information with others — should you want to do it. You simply type in someone’s email address in there, and you grant them reader or admin privileges to your stats accounts. Instantly, they can examine your stats. Should you prefer not to do that, you can quickly export your stats data in PDF or spreadsheet format, so you can attach it to an email or print it out, and share the information that way.

I envision Google Health working the same way. Once you’ve got your information together, you can quickly grant a new doctor access to your record, so they can look at all your medical history or lab results. You’ll be able to easily print out immunization records for your children, or just email them to their school so they can enroll in classes. A system like this is priceless in my opinion, because it’ll make it easy to keep track of one’s health information. Remember, it’s YOUR information, and it should NOT stay locked away in some hospital’s records room somewhere. You should have ready access to it at any time.

Notice I said “whose aim is to pull together all the disparate bits of information you WANT to pull together” a couple of paragraphs above. That’s because you can readily delete any conditions, medications or procedures you’d rather keep completely private from Google Health. Should you import certain things into it that you don’t feel safe storing online, just delete that specific thing, and keep only the information you’d be comfortable sharing with others. It’s easy; try it and see.

Lots of work has already been done

Another concern voiced by others is that there isn’t much to do with Google Health at the moment — there isn’t much functionality, they say. I disagree with this as well. Knowing how hard it is to get health systems talking to each others, and knowing how hard it is to forge the partnerships that allow data sharing to occur, I appreciate the significant efforts that went on behind the scenes at Google Health to bring about the ability to import medical data from the current 8 systems (Beth Israel Deaconess, Cleveland Clinic, Longs, Medco, CVS MinuteClinic, Quest, RxAmerica and Walgreens).

What’s important to consider is that Google needed to have the infrastructure in place (servers, databases) ready to receive all of the data from these systems. That means Google Health is ready to grow as more partnerships are forged with more health systems.

In order to illustrate how hard it is to get other companies to share data with Google Health, and why it’s important to get their staff on board with this new development in medical records maintenance, I want to tell you about my experience linking Quest Diagnostics with Google Health.

Quest is one of the companies listed at Google Health as having the ability to export/share their data with my Google Health account. What’s needed is a PIN, a last name and a date of birth. The latter two are easy. The PIN is the hard part. While the Quest Diagnostics websites has a page dedicated to Google Health, where they describe the various benefits and how to get started, they ask people to contact their doctors in order to obtain a PIN. I tried doing that. My doctor knew nothing about it. Apparently it’s not the same PIN given to me when I had my blood drawn — by the way, that one didn’t work on Quest’s own phone system when I wanted to check my lab results that way…

Quest Diagnostics lists various phone numbers on their site, including a number for the local office where I went to get my bloodwork done, but all of the phone numbers lead to automated phone systems that have no human contact whatsoever. So Quest makes it nearly impossible to get in touch with a human employee and get the PIN. Several days later, in spite of the fact that I’ve written to them using a web form they provided, I still don’t have my PIN and can’t import my Quest Diagnostics lab results into my Google Health account.

➡ Updated 5/27/08: Make sure to read Jack’s comment below, where he explains why things have to work this way with Quest — for now at least.

That is just one example of how maddening it is to try and interact with healthcare organizations, so let me tell you, it’s a real feat that Google managed to get eight of them to sign up for data sharing with Google Health. It’s also a real computer engineering feat to write the code needed to interact with all those various systems. I’m sure Google is working on more data sharing alliances as I write this, so Google Health will soon prove itself even more useful.

More work lies ahead

I do hope that Google is in it for the long run though, because they’ll need to lead data sharing advocacy efforts for the next decade or so in order to truly get the word out to patients, healthcare organizations and providers about the benefits of data sharing and Google Health.

For now, Google Health is a great starting point, with the infrastructure already in place and ready to receive more data. I’m sure that as the system grows, Google will build more reporting and data export capabilities from Google Health to various formats like PDF, as mentioned several paragraphs above, and then the system will really begin to shine. I can’t stress enough what a good thing this is, because just like with web search, it puts our own medical information at our fingertips, and that’s an invaluable benefit for all.

Join me for a short screencast where I show you Google Health. You can download it below.

➡ Download Google Health Screencast

(6 min 28 sec, 720p HD, MOV, 39.8MB)

Standard
How To

How to install or upgrade WordPress via SSH

If you know how to log in via SSH (Secure Shell Access), then you will be able to upgrade your WordPress site in three minutes or less by using the following lines of code.

I have to admit right away that I’m highly indebted to this pre-existing tutorial from Techtites. But that tutorial is a little dated for the newer versions of Linux, and one of the commands given there no longer works on my web server, because it’s been deprecated (I use 1and1). I thought it useful to provide the right commands in this post, and to keep it updated in case something changes.

A few words of CAUTION:

  1. BACK UP all of your site files and your site database before running the upgrade. Take the time to do both, or you may deeply regret it later. As a matter of fact, it’s a great idea to back up your site files and database on a weekly basis, if not more often, just in case you get hacked or the web server crashes, etc.
  2. I’m not a Linux expert. I’m just glad I found these commands and that they’ve made the upgrade process easier for me. Don’t ask me to help you configure this for your web server. If the commands don’t work there, or something gets screwed up, you’re on your own.
  3. Should you use the WP-Cache plugin, disable it and delete any cached files BEFORE running the upgrade process. Even better, disable ALL your plugins before the upgrade process. If you don’t do this, you may get a big, fat 500 error afterwards.

Now, initiate a SSH session to your web server (I use Putty). Your web host should have the directions on how to do this. Go to the root level of your site/WP install folder (this is NOT the same as the root level of your SSH login).

Once you’re at the root level of your WordPress install (the one where you can see the wp-config.php file), enter the following Bash commands, in the order they appear. Wait for each of them to execute successfully before proceeding to the next one.

This will download the latest version of WP directly from WordPress.org:

wget http://wordpress.org/latest.tar.gz

This will unzip it, creating a directory called wordpress:

tar xfz latest.tar.gz

This will delete the wp-includes and wp-admin folders:

rm -rf ./wp-includes/
rm -rf ./wp-admin/

This will take you inside the wordpress folder:

cd wordpress/

This will copy everything inside the wordpress folder to the root level of your site, overwriting any existing files and directories. This line is the only line that’s changed from the Techtites tutorial:

cp -rpf -f * ../

This will take you back out to the root of your WordPress install:

cd ..

This will delete the wordpress directory and the downloaded WP archive, since they’re not needed any more:

rm -rf ./wordpress/
rm -f latest.tar.gz

Hope this helps!

Standard
How To

How I moved all my content from comeacross.info to raoulpop.com

A place in this world

Background info

As midnight approached this past New Year’s Eve, I was busy working on a long-term project. I was about to move all of my content (every article and post I’d written) from comeacross.info to raoulpop.com. There were many reasons for this, but consolidation was the most readily apparent.

As detailed on my About page, I’d already combined my content from other sites of mine onto comeacross.info, but there was one more piece of the puzzle that needed to fall into place. I’d alluded to it already. I was thinking about doing it in 2006, believe it or not. As a matter of fact, when I sat down and thought about whether to start writing at comeacross.info or raoulpop.com, I knew deep down I should choose to start writing on my personal domain, but worried it might be too difficult for people to remember and type the name.

After a year or so at ComeAcross, I realized that the subjects I was writing about were much too varied for a standalone site. I was writing in a personal voice, using a lot of 1st person, and it only made sense to have that sort of content reside on my personal site. Plus, there were so many splogs (spam blogs) on the .info TLD, that I worried whether I would be taken seriously if I stayed on .info. I’d owned raoulpop.com for a long time, I wasn’t really putting it to good use, and it didn’t make sense not to.

I set a deadline of 12/31, and got to work on planning and research. What better time for such a big change as this than New Year’s, right?

I’m documenting this for you because someone else might need to know how to do it. And I figure the thought process that went on behind the scenes is also worth knowing.

Planning and research

My biggest challenge was to figure out how to redirect all of the traffic from comeacross.info to raoulpop.com, reliably and accurately. I needed to make sure that every one of my articles and posts would redirect to my new domain automatically, so that a URL like

http://comeacross.info/2007/12/30/my-photographic-portfolio/

would automatically change to

https://raoulpop.com/2007/12/30/my-photographic-portfolio/

and the redirect would work in such a way that search engines would be properly notified and I wouldn’t lose my page rank.

I knew about 301 redirects, but I wasn’t sure how to accomplish them in the Linux/WordPress environment the way that I wanted them to work. I had worked mainly with Microsoft web servers until recent times, and Linux was and still is fairly new to me. I was using John Godley’s Redirection plugin for WP (it’s an awesome plugin btw), and I knew it could do 301 redirects quite nicely. I had been using it heavily when I changed post slugs or deleted/consolidated posts at ComeAcross.

I worked out a line of Regex code that I could use to create a site-wide redirection, I tested it and it worked fine. In case you’re wondering, you can easily test it by creating a 307 (temporary) redirection instead of a 301 (permanent) redirection. Here’s how to do it:

Create a new 301 redirection where the source URL is

/(.*)

and the target URL is

http://www.example.com/$1

Make sure you check the Regex box, add it, and you’re done.

Just to make sure, I contacted John Godley to confirm whether it was the best way to do things. He said that would certainly do the job, but there was a MUCH easier and faster way to do it, one that saves a lot of the overhead that comes into play when WP gets used. It works through the .htaccess file. He was kind enough to provide me with the code, which is reproduced below.

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

</IfModule>

Just paste that into your .htaccess file (remove all other code but make sure you back it up somewhere in case you need it), save it, upload it, and you’re done.

Don’t do anything yet though! Not before you’ve thoroughly backed up everything! Let me outline the steps for you, and keep in mind that I wanted to mirror all of my content from two separate WP sites using the same WP version, and to redirect from the first to the second. These two conditions have to be met in order for my advice to apply to your situation.

  1. Make sure both sites are on the latest and greatest version of WP, or at least they’re on the SAME version of WP
  2. Back up the database from the old domain
  3. Download all site files from the old domain
  4. Upload site files to new domain
  5. Restore database to new domain
  6. Make changes to .htaccess file as shown above
  7. Log into your new domain’s WP admin panel and change the site and blog URLs. Now you’re done! Check to make sure the redirection works properly and all of your content is there.

Upgrade your WP installs

The two sites have to be on the same version, or else things might not work as expected. Upgrade both sites to the latest and greatest, or at least make sure they’re on the SAME version before you do anything else. Go to WordPress, download and install the latest versions. There’s also an Automatic Upgrade plugin, but I haven’t tried it yet, so I can’t vouch for it.

BEFORE you do any sort of upgrade, you need to back up. Yes, you can’t get away from this… You’ll need to do two backups, one before you upgrade, and one after you upgrade, before you transfer the content.

Back up your content

This combines steps 2 and 3 listed above. Backing up your site files is easy. Use an FTP client to access the files on the web server and download them to your hard drive. I always keep a local copy of my site files. It just makes sense.

Backing up your database is a little more involved. Your database contains all of your site content (posts, links, comments, tags, categories, etc.) so you definitely don’t want to lose it. There are detailed instructions on backing up the database on the WordPress site. You can follow those, or you can go to your site’s Admin Panel >> Manage >> Export and download the WordPress WXR file, which you can import into your new site afterwards.

While this is great for backups, restores are another matter. I tried it and found that the import operation kept timing out at my web host. Given that I have thousands of posts, I didn’t want to sit there re-restoring the WXR file only to get a few posts done with every operation. I needed something quicker.

There is a plugin called WordPress Database Backup which lets you download a zipped SQL file of the database. You can use this to restore the database through the MySQL Admin Panel, if your webhost provides you access to it.

What I did was to simply point my new site install to my old database. This is a very handy and easy solution if you plan to host both sites with the same web host. But this still doesn’t excuse you from backing up the DB before you upgrade the WP install! 🙂

Restore your content to the new site

This is a two-step process (see #4 and #5 above) and involves reversing the steps you took during the backups. You will now upload your site files to the new domain, and you will restore the database to the new domain as well. If you’re in my situation, where you’re using the same web host, you can simply point the wpconfig.php file on your new domain to the old database.

Make sure all your content is properly restored before going on to the next step!

Make changes to the .htaccess file

You will need to make sure you don’t touch the .htaccess file before you transfer it to your new domain. Only the .htaccess file on your old domain needs to change. Remember this, or you’ll be wondering what’s going on with the redirects afterwards…

Use the code I’ve given you above, in the Planning and Research section, to make changes to the .htaccess file on your old domain, after you’ve made absolutely sure that all of your content is now mirrored on the new domain. Once this is done, the redirects will occur automatically and seamlessly.

Final checks and tweaks

This is very important. Surf to your old URL. You should get re-directed to your new URL. Do a search in the search engines for content of yours that you know is easily found. Click on the search results and make sure the links get redirected to your new site. Because you’re using 301 redirects, the search engines will automatically change their search results to reflect the URL changes without affecting your page rank, so you shouldn’t lose any search engine traffic if you execute the content move correctly.

There are a few more things you’ll need to check:

If you’d like to make changes to your site feed (and I did), you’ll need to handle that properly. I use FeedBurner, and there are people that subscribe to my content via RSS or via email. I needed to transfer both groups of subscribers to my new feed seamlessly. The FeedBurner folks helped me do just that, and I didn’t lose a single subscriber during the move. I detailed that process in this post.

What about internal links? If you’ve blogged for a while, you’ll have linked to older posts of yours. Those link URLs now contain the old domain, and you’ll need to change all of them at some point, or you’ll risk making those links invalid if you should ever stop renewing your old domain. Fortunately, there’s a Search and Replace plugin for WP that lets you do just that. It works directly with the database, it’s very powerful, and it’s very fast. That means you have to be VERY careful when you use it, because there’s no undo button. You can easily mess up all of your content if you don’t know what you’re doing.

What I did was to replace all instances of “.raoulpop.com/” with “.raoulpop.com/“. That did the trick nicely. I then did a regular site search for all instances of ComeAcross and manually made any needed changes to those posts. (Here’s a thought: back up the DB before you start replacing anything. This way you can restore if something should go wrong.)

Finally, if you’re using the Google Sitemaps Generator plugin, you’ll want to make sure you manually rebuild your site map. You don’t want to have your old site information in the site map as Google and the other search engines start to crawl your new domain.

That’s about all I did for the site content transfer. It occupied half my New Year’s Eve night, but it was worth it. It’s quite a bit of work, but if you plan it out, it should only take you 4-5 hours or less to execute the transfer, depending on your familiarity with this sort of thing, and the speed of your internet connection (keep in mind that upload speeds are a LOT slower than download speeds on most broadband connections).

Given how much work is involved, I was a bit surprised to see Matthew Mullenweg (founding developer of WordPress) talk about doing his own switch to a new domain in “2 seconds“. I think what he referred to is the changes to the .htaccess file and the blog URLs, which are the fastest parts of the process. There is, however, quite a bit of work that needs to take place behind the scenes before those switches can get flipped. And I also believe (someone correct me if I’m wrong) that he pointed both domains to the same web files — in other words, re-used his existing WP install — so he bypassed a lot of the steps that are otherwise required.

Hope this proves helpful to someone!

Standard