TPB says that they want to have their servers flying over international waters.

While I’m sure that this is pretty unrealistic, though certainly do-able, if they actually get it to work then there’s only one real response I can make:

On another note though, I don’t see how this solves their basic problem. They still have to have that radio link on some shore somewhere. In a sense, this is no different than if they put the things on a boat and ran a bunch of cables to land. Ignoring potential attacks on the boat, those cables have to touch ground somewhere, and that’s the point of attack. Unless you have lots of them and have them possibly mobile, which is at least more feasible with radio than with undersea cables.

I suspect that the idea is more of a political talking point. They do seem to love coming up with those.

I would never recommend NetSol for any sort of service of any kind, but damn if they can’t make a funny parody.

Google has a pretty neat interactive Doodle for Thanksgiving…

• Pirate: http://g.co/doodle/7gmtj5
• Wizard: http://g.co/doodle/y4rs2x
• Beanie hat on bicycle: http://g.co/doodle/enz2bt
• Disco Roller Skater: http://g.co/doodle/zskwej
• Astronaut: http://g.co/doodle/my24pw

There’s more, but I haven’t found them all yet. To find them, just get the right combination of shoes, hat, and feathers and poof, it transforms.

This tweet got me to thinking about the myriad uses of technology used for rather simple things.

Weather Station Example

For example, the weather. The National Weather Service has set up climate observation stations throughout the US, at places like airports, on top of tall buildings, alongside freeways, random places in the countryside, even on ships and buoys in the ocean. These monitor the temperature, humidity, and a bunch of other things of that nature. Sometimes they’re integrated into the overall system, like at an airport tower, sometimes they’re just self contained boxes mounted somewhere with power, like on a freeway sign or beside the road. Anyway, these boxes record this information and generally use radio transmitters to send updates back to some centralized location in each region. Usually a local university, TV station, NWS local offices, etc.

This information is then sent on to the next stop via various methods. As the technology evolved, old methods like phone lines got replaced with the internet, or on other more secure lines. They call this overall system The Gateway, and it has its own special protocols and methodologies along with it as well. Anyway, the data is sent back to the NWS’s central server center somewhere. Probably in DC, although they likely have multiple redundancy in various other locations. This information is naturally combined with all the other information from all over the world, so that a complete up-to-date system of meteorlogical data of the entire world can be maintained.

Thousands of other organizations read from this data via various protocols of their own. For example, The Weather Channel gets a lot of their information from this large, distributed, database via some kind of real time feed. They even re-serve the data themselves using various formats, such as the XOAP system.

That XOAP system is interesting because it’s a pretty good feed of weather related data for various regions. I use it myself, indirectly. On my iPhone, for example, I have the Typophone Weather application, which uses the 3G network (which is itself a highly connected system of radio towers using multi-spectrum packet switching technologies), to connect to the internet (this big system of pipes which is in reality not all that well put together but nevertheless works because of incredible fault tolerance in its various protocols), in order to query that XOAP system (which uses XML and SOAP standards for its interface).

All this happens in order to display the current temperature on my iPhone’s lock screen, while I sit here on a couch, not four feet from a friggin’ window.

The future is awesome.

A while back, the personal genetic testing company 23andme offered a special sale. They discounted their normal price from $500 to $99 for one day only. Naturally, I jumped on it.

Just got my results back. Nothing particularly surprising here, but it is neat.

• My blood type is A (A/O). I knew this, good to see it backed up by genetics.
• I have an elevated risk for Type I and II diabetes (no news here, my sister is diabetic).
• Apparently, I can’t taste “bitter”. This does explain why I love Brussels Sprouts.
• I’m lactose intolerant. I was pretty sure of this already.
• I have a natural resistance to norovirus (stomach flu). Didn’t know that.
• I am a carrier for Cystic Fibrosis. I don’t have it, but it’s possible that my children could.
• I am a slow caffeine metabolizer. It says that drinking coffee increases my heart attack risk (duh), but I’m not sure what this really means. Caffeine typically doesn’t do a thing to me, at least not immediately. I go through a fair amount of it on a regular basis.
• Paternal Haplogroup: I1*, Maternal Haplogroup: H1. This basically makes my ancestry 100% European. Very vanilla there. However, this does conflict with my known ancestry slightly, in that it says I don’t have any Native American ancestors (within 5 generations). But then again, I don’t have a whole lot of reliable information on that branch of the family tree.

There’s a ton more information (apparently I’d respond really well to Interferon Beta Therapy, whatever the hell that is), and I haven’t gone through it all yet.

One thing I did note is that they do allow you to download the raw data, which is pretty cool. However when I looked at it, I noticed that it’s not a complete record of your DNA, just a sampling. Basically it’s like 500,000 markers of it instead of the full 3 billion or whatever. Clearly you don’t need the complete sequence to draw useful information out of it.

Still, kinda neat that this is within the reach of the average person.

Since people have been emailing me and asking for it…

WordPress Plugin: Simple Twitter Connect

It’s similar in concept to the Simple Facebook Connect plugin. In fact, it rips off quite a lot of the same code. But instead of Facebook, this integrates your WordPress site better with Twitter.

Now, there’s a lot of Twitter plugins out there already. And this plugin by no means competes with them (yet). This plugin can’t, for example, send a post to Twitter (yet). Nor can it pull posts from Twitter to display on your own site (yet).

What it does is to provide the framework for a more complete Twitter integration. Right now it can do:

• Login via Twitter
• Comment via Twitter

Not much, really. But it has the backend code necessary to make it easier to connect your site to a Twitter Application, and to make plugins surrounding it that won’t interfere with each other. That’s the same basic reason for the Simple Facebook Connect plugin.

So yes, eventually this plugin will send and receive stuff from Twitter. But for now, it lets you allow users to Login and/or to have users Comment using their Twitter credentials.

Expect frequent updates.

Edit: This post has moved to here: http://ottopress.com/2010/dont-include-wp-load-please/. Take your comments there.

Time for Otto’s general griping: WordPress plugin programming edition.

Here’s a practice I see in plugins far too often:

1. Plugin.php file adds something like this to the wp_head:

   <script src='http://example.com/wp-content/plugins/my-plugin/script.js.php'>

2. Script.js.php has code like the following:

   <?php
   include "../../../wp-load.php";
   ?>
   ... javascript code ...
   

The reason for this sort of thing is that there’s some option or code or something that the javascript needs from the database or from WordPress or whatever. This PHP file is, basically, generating the javascript on the fly.

Usually, the case for this turns out to be something minor. The code needs the value from an option, or some flag to turn it on or off. Or whatever.

Problem is that finding wp-load.php can be a bit of a chore. I’ve seen extreme efforts to find and load that file in plugins before, including searching for it, examining the directory structure to make decent guesses, etc. This sort of thing has existed even before wp-load.php came around, with people trying to load wp-config.php themselves and such.

But the real problem is simpler: This is always the wrong way to do it.

Why this is wrong

1. You don’t have the first clue where wp-load.php actually is. Both the plugin directory and the wp-content directory can be moved around in the installation. ALL the WordPress files could be moved about in this manner, are you going to search around for them?
2. You’ve instantly doubled the load on that server. WordPress and the PHP processing of it all now have to get loaded twice for every page load. Once to produce the page, and then again to produce your generated javascript.
3. You’re generating javascript on the fly. That’s simply crap for caching and speed and such.

The right way? Well, there’s two options.

Right Way the First

Generate your options separately, put them in using wp_print_scripts.

Examine this pseudo-code:

add_action('wp_print_scripts','myscript');
function myscript() {
?>
<script type="text/javascript">
  var plugin_option= <?php echo json_encode(get_option('plugin_option')); ?>;
</script>
<?php
}
wp_enqueue_script('myscript','...myscript.js',...);

Basically, the plugin option value is inserted directly into the page. The myscript.js file that loads shortly afterwards can use this value however it likes.

Why this is better:

1. No searching for wp-load.php.
2. The javascript is static, only your options are variable. No added load on the site.
3. Static scripts mean you get great speed from caching.

Sidenote: Note the use of json_encode? You should always use this when producing javascript variables from PHP variables. It handles quoting and escaping and everything for you. It can even turn PHP arrays into javascript arrays nicely! Handy for storing all your options in one place.

What if you have a ton of plugin options though? What if you really WANT to generate that javascript on-the-fly?

Right Way the Second

Generate the javascript from a call to WordPress itself, not to a separate file.

Examine this pseudo-code:

add_filter('query_vars','plugin_add_trigger');
function plugin_add_trigger($vars) {
    $vars[] = 'plugin_trigger';
    return $vars;
}

add_action('template_redirect', 'plugin_trigger_check');
function plugin_trigger_check() {
	if(intval(get_query_var('plugin_trigger')) == 1) {
	?>
function javascript_code() {
...
}
<?php
	exit;
	}
}

That code does something a little clever. Basically it’s adding a new query variable to be used as the “trigger”. When the trigger gets pulled, a bunch of javascript is generated, then the code *exits*, stopping WordPress from proceeding any further.

So, with that code in a plugin, a call to http://example.com/?plugin_trigger=1 will now produce your javascript code. This is running entirely within the content of a WordPress call, so you get all the WP functions and database access with which you can generate your code as well.

Thus, you can happily put your

<script src="http://example.com/?plugin_trigger=1">

code into the page and it’ll load up that “file” just fine.

Why this is better:

1. No searching for load.php
2. … Well, okay, there is no other reason. The load problem still exists, and your caching issues still exist. You’re programmatically generating code here, after all. It’s not a particularly good practice to do. Still, sometimes this is easier and faster to develop, even if it’s never actually “necessary”.

Also see that while I’m using the number 1 there as the value I’m checking for, that value can be anything you like. If you want to be a smartass about it and have all sorts of different things that could be generated, you can do them all with that one trigger. It’s still a generally bad idea because of the added load, but hey, maybe you have a legitimate reason. I’ve seen one or two valid reasons to do this before.

Wrap up

Also note all of the above also applies to “generating” CSS code. It’s just as unnecessary. Usually more so.

So please, stop including wp-load. It’s just wrong. Let WordPress load itself, and make your plugin do the output it needs to produce in the right places.

Note: This post has been moved to here. Please leave comments there instead.

The majority of the email I get from users of the Simple Facebook Connect plugin is questions regarding how to setup their Facebook Application. It’s really not that hard to do, but the plethora of options can seem somewhat intimidating. So here’s the basics of what you need to do.

After creating your application, you’ll need to visit the Apps section in the Facebook Developer Home area. Here you’ll find your application, and the all critical “Edit Settings” link.

Firstly, never give out your Application Secret. If you give this out by accident, then use the Reset Secret Key link to get a new one.

Anyway, from here, you want to go into the settings. The settings area is divided into six main sections, but most of the settings are irrelevant. See, you’re building a “Connect” application, not a “Canvas” one. So most of these are meaningless for you. The following ones are what you actually care about:

Obviously, you want the name of your Application to make sense. I suggest using the same name as your website. You can even use your domain name here if you like. Just be aware that this name is what the Fans of your site will see in their Applications area.

The Basic Information section is important as well, fill it in as you see fit. I also recommend uploading good icons and/or logos for your site. Gives it that finished look.

Contact Information is obviously important as well, but don’t worry about all those extra URLs. They really apply more to Canvas apps. Of course, if you want to make special pages on your site for them and provide the URLs here, feel free.

The Authentication Settings page is surprisingly important. Those top two boxes need to be unchecked for a Facebook Connect application. Why? Because when they are unchecked, your Application becomes an “External Website” as far as Facebook is concerned. If you have either them checked, then your app’s Canvas section becomes active and you might have users trying to add it to their profiles and such, resulting in broken pages and a general bad user experience.

The Connect Settings page is probably the most important one. These settings must be filled in and they must be absolutely accurate. Specifically, the URLs must be the URLs that are actually used by your site. Capitalization matters. The leading “www” or lack of one matters. Whatever the URL your site is in the browser is what you MUST put into these fields. Anything less and your site will not work.

The Advanced Settings screen contains these three fields which you need to set in the same way I did. The email domain should be your own domain, obviously. This field must be filled in for you to get real user emails on your Connected site. Without this, you only get proxied emails through Facebook.

Finally, after you have saved those settings, take the time to go back to the main application screen and click the “Edit Application Profile” link. You’ll be taken here, where you can set up the “look” of your application page on Facebook. This includes what tabs are visible, the stuff in the Info section, etc. You can add extra Applications tabs to this page and generally customize all sorts of stuff. None of that affects your site, but it does affect how the App Page looks in Facebook. The more polished it is, the more likely people will “Fan” your Application. And Fans get updates from when you publish posts to the Wall. Great way to drive traffic to your content.

Hope this helps! Mainly, I hope this reduces the number of questions I get about this process. Enjoy SFC!

I saw this morning that Jesse Stay had created a rather neat little chicklet for his FBFoundations plugin. I thought it was a clever idea, so naturally I stole it and added it to Simple Facebook Connect as well.

Of course, just copying an idea is no fun. So I had to improve upon it a bit for my version.

I ended up not using any of Jesse’s code, but I did (mostly) keep the format of his chicklet output the same, so as to try to be compatible with it for styling rules and such.

Usage

The SFC Chicklet works in one of a few ways:

• First, it’s a widget if you just want to stick it in a sidebar or something. That’s easy.
• On the other hand, if you want to integrate it into your theme, then all you have to do is to add a call to sfc_chicklet(); anywhere you like.

Configuration (Styling)

Now, unlike Jesse’s FBFoundations plugin, Simple Facebook Connect is all about simplicity. So I removed all the configuration options that he used (widths, colors, etc) and made them styleable instead.

The SFC Chicklet has a default set of styles that it puts right into the HTML itself. However, these can be easily overridden by your own styles in your theme. The thing to notice is that all the styles I use refer to classes only, not referencing the tags. So, if you re-style and use the tags as well, then your styles win the specificity war, and will take precedence.

Thus, if you want to change the background color of the main box, you can do this:

div.fanBoxChicklet {
background-color:blue;
}

Simple. The “div” makes it take precedence. Anybody familiar with simple CSS should be able to easily style it the way they like.

On the other hand, if you’re a super-themer and want to disable the built-in styles entirely, add this to your theme’s functions.php file:

global $sfc_chicklet_no_style;
$sfc_chicklet_no_style = true;

Extra

And, of course, this new plugin supports both the Application and the Fan Page methods, for those of you who have your webpage hooked to a Fan Page. This is similar to the new support for Fan Pages in the SFC Publish and SFC Fan Box plugins.

If you’re a real power user, you might want to display a chicklet for more than one page or application. Well, we’ve got you covered, just call sfc_chicklet(“ID-NUMBER”), where ID-NUMBER is the ID of your application or page. Remember, this needs to be a string, not an integer.

Internals

Internally, the plugin uses the Facebook PHP library to get the necessary data from Facebook, so there’s no need to have any odd javascript or ajax requests to make the system work. Because of the use of this Facebook code, PHP 5 is required to use this plugin.

However, the Facebook code includes a JSON library (if you don’t have one already loading), which means that if you activate this plugin, it’s quite probable that the whole SFC system will run on WordPress 2.8, even if it wouldn’t before. Of course, since 2.9 was just released, this is not as big of a deal, really.

The plugin also uses the WordPress Transients API as a caching mechanism, so that it only asks Facebook for the fan count a maximum of once per hour. The Transients API was introduced in 2.8, and so the plugin should still work okay if you haven’t upgraded to 2.9 yet.

And if you can come up with any other good Facebook plugin ideas, let me know. SFC has proven to be an easy platform for building simple Facebook plugins on top of, so they can probably be produced pretty quickly and easily.

Installation

If you haven’t installed SFC yet, then this chicklet is part of the package. Just download it and install from here:
http://wordpress.org/extend/plugins/simple-facebook-connect/

Alternatively, in a WordPress installation, just go to the “Plugins->Add New” area and search for “Simple Facebook Connect”. You can install the package directly from there.

If you already are using SFC 0.8, then you only need the new file. You can download it separately here:
http://plugins.svn.wordpress.org/simple-facebook-connect/trunk/sfc-chicklet.php

Just drop it into your /wp-content/plugins/simple-facebook-connect directory, then activate it in the Plugins panel.

Heard of geotagged tweets yet? Not surprised, a lot of my friends seem to have not caught on to it, so I’m writing this in a possibly futile attempt to get them to try it out.

How to add your location to your tweets

1. Turn on Geotagging. To do this, go to your Twitter settings page. Down under the “Location” section is an option to enable geotagging. Turn it on.

Twitter Settings

2. Get a Twitter client that supports Geotagging. These are generally mobile applications. Tweetie 2 for the iPhone added support for it in 2.1. Several other clients support it as well. Find one.

3. Turn it on in your client. How you do this depends on the client, but it can usually be enabled on a per-tweet basis.

Here’s an example of how it works and looks in Tweetie 2 for the iPhone.

First, you type in a new tweet, and pull open the drop down.

Next, you enable the geotag feature, and you'll see a little red pin appear.

You'll see little maps on tweets with locations attached to them.

Click on the map icon for greater detail.

You can do more with your Twitter location too. For example, this website will read your twitter feed and get your latest location, then send it over to Fire Eagle, which is Yahoo’s location service. Fire Eagle can do all sorts of things, but basically it’s just a service that stores your location for other programs to use. So if you want to display your location on your blog, or on Facebook for your friends to see, or anything else you can think of, you can do that, using nothing more than your already existing tweets.