Tag Archives: google

Quick note: iconv and Building PHP on OSX

When attempting to build PHP 5.3.6 on OSX (Snow Leopard) I got warnings about iconv, which I had installed via ports.

Undefined symbols:
  "_iconv_close", referenced from:
      __php_iconv_strlen in iconv.o
      _php_iconv_string in iconv.o
      _php_iconv_string in iconv.o
      __php_iconv_strpos in iconv.o
      __php_iconv_mime_decode in iconv.o
      __php_iconv_mime_decode in iconv.o
      __php_iconv_mime_decode in iconv.o
      _zif_iconv_substr in iconv.o
      _zif_iconv_substr in iconv.o
      _php_iconv_stream_filter_dtor in iconv.o
      _zif_iconv_mime_encode in iconv.o
      _zif_iconv_mime_encode in iconv.o
 ... etc

To get around this, I had to:

./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-iconv=shared,/opt/local

OS 3, CalDav: update

In addition to Shep’s helpful comment, right after I posted my last entry I discovered that the settings at m.google.com/sync apply to the Exchange sync. Apparently the Exchange sync worked in OS 2.2, so there was no reason to upgrade at all, if I had just known that.

Of course, there are some nice additional features that I got, and it was only $10, but it’s rather irritating to me that I have to set up 10 different accounts to sync my 10 different Google calendars. That seems odd, to say the least.

Anyways, perhaps this is an enhancement that will come along shortly. Meanwhile, I’ll probably just keep using the Exchange connector.

OS 3.0 and CalDAV

I had one single motivation for upgrading my iPod Touch to OS 3.0 – CalDAV. According to very vague reports I had read before, it would “support CalDAV”, although the actual explanations of what that meant varied somewhat.

But iCal on the Mac started supporting CalDAV – actually allowing editing of CalDAV calendars – a while back, so I figured maybe the iPod/iPhone would too. And, hey, it’s only $10.

I found several conflicting instructions on how to configure CalDAV for Google Calendars. The best ones were here and here, suggesting that you set it up either as an Exchange account or a CalDAV account. While CalDAV seems more probable, the one that says to do it as Exchange is at Google. Weird.

Also, if you go to m.google.com/sync on your iPhone, you get a thing that lets you select which of your calendars you wish to connect to.

So far, sounds pretty good.

Yes, I said “which of your calendars.” I have a dozen calendars on my Google calendar account, because I share calendars with several people. It’s the only way to fly. But the iPhone seems to assume that I’ve only got one. As far as I can tell, it is syncing quite happily with one, but the other ones are being entirely ignored, despite what I configured on m.google.com.

Is this expected? I vaguely remember reading somewhere that I’d have to create a “new account” for each calendar, but that’s so completely ludicrous that I must have misunderstood, right? In that case, why would there be this tool at Google for saying what calendars I want to sync?

I *think* I have it set up right now, but now m.google.com says that my iPod hasn’t sync’ed since yesterday at 15:46, so … apparently something is still not set up right.

So. Frustrating.

Spam Bait

Fitz notes that his email address appears 960 places on the web. I’m at 2630. This is one of the reasons that I’ll very soon (hopefully tomorrow) switch my primary domain over to the Google for Domains service (or whatever they’re calling it now), so that I can get out of the spam fighting business. I’ve spent an inordinate amount of time over the last 12 years or so trying to figure out how to get less spam to hit my inbox, and I’m all done. Google’s got folks who do that full time, and, while I can’t figure out why they would provide this to me for free, I’m perfectly willing to let them.

MYTH: Pretty URLs == Search Engine Optimization

Having become a bit of a self proclaimed expert on mod_rewrite, I spend an inordinate amount of time answering mod_rewrite questions on #apache, on irc.freenode.net.

Unfortunately, much of that time is utterly wasted on something known as “Search Engine Optimization”, or SEO. SEO is an industry that has grown up around profound ignorance about how search engines work, and the basic theory goes like this. Certain URLs are “bad” and others are “good”, and you need to use mod_rewrite to convert “bad” URLs into “good” ones. Bad URLs are those that contain “?” and “&” and “=” and other non-alphanumeric characters. Thus, one must use mod_rewrite to create URLs that lack these characters.

This is all very well except for one thing – it’s nonsense, utterly untrue. Now, it may have been true 10 years ago, but since then, search engine algorithms have gotten better, and it’s just not the case any more.

Below is a comprehensive list of the search engines that matter:

* Google

The algorithm used by the search engines in this list goes basically like this: If your content is worthwhile, other people will link to you. Therefore, sites that have a lot of links to them are good sites and should appear at the top of searches.

That’s it. Nothing to do with the characters appearing in the URL. So if you’ve paid some SEO firm a great sum of money to increase your search engine ranking, the chances are very, very high that you’ve wasted that money.

And yet, it seems that more than half of the questions that we field on #apache have directly to do with this false belief in the principles of SEO. This is a great shame, since there are actually some people with legitimate questions, and they have to wait for the nonsense.

Now, notion of “good URLs” does have one redeeming quality. URLs that are easier to read to someone over the phone, and easier to remember, have a certain amount of value in marketing. This is undeniable. For this purpose, Apache provides the Redirect directive, whereby you redirect the easy-to-remember URL to the actual URL.

Another useful technique is to actually design your website with non-convoluted URLs from the start.

However, none of these techniques will improve your search engine ranking if your content isn’t good. Content is important. Your URL isn’t important.

I realize that there are folks who are convinced of the necessity of creating “pretty URLs”, and reading this article won’t in any way dissuade them. The reasoning seems to go that everybody is doing it, and therefore it must be right. I’ll not waste your time with explaining the fallacy in this position. I will, however, direct you to the page that Google themselves have compiled to tell you about how their search algorithms work.

And, yes, I know that there are actually other search engines that matter. Their ranking algorithms are not so very different, and even when they are, the people programming them are not so stupid as to be unaware that almost every site on the web is composed of applications that load content out of databases, and are therefore likely to have URLs containing query string characters. So de-valuing sites that contain those characters in their URLs would be exceedingly counterproductive. Give them some credit.

Updated Sept 20 18:43: Note that I’ve updated the title of this article, due to some of the feedback in the comments. I concede that there may be people in the “SEO” industry who are not snake-oil salesmen. I can even somewhat believe that all the satisfied customers never make it to #apache, and the folks who are there are the very ones who received bad advice. It’s more than a little damning that every SEO website that I’ve looked at is full of terrible advice. Presumably, then, the folks who are are good at their job are just being secretive.