This is done on my Schwinn 231 Recumbent Exercise Bike.

Created by Oatmeal

It’s interesting in light of the recent reports on kids and hearing loss.

This is done on my Schwinn 231 Recumbent Exercise Bike.

I was in the office working with Peter earlier this week when his cell phone took a “pocket photo”. That is, his cell phone, in his pocket, decided to take a photo, all by itself.

When I picked up my phone on launch day, I got an Apple bumper case to make sure I could protect it–turns out this was a good idea.

What Apple did right, they automatically issued a refund–I didn’t have to do anything to get it. On July 22, I got an email with…

Source: Brandon/Apple

Thanks, I didn't have to do anything!

Thanks, Apple!

Evaluability Assessment is described as, “A strategy that can be used to determine the extent to which a program is ready for full evaluation.” (Trevisan and Huang, 2003) And it has been described as a method to “assess the likelihood that prgram activities will reach mesuarable progress toward program objectives; and assessthe extent to which evaluation information is likely to be used by program management.” (Whorley, 1979)

I interpret this as the “reality check”–what I’m interested in in most projects is the project reasonable and is it likely to have a reasonable outcome.

Leviton and Gutman (2010) caution that, “EAs are a preevaluation activity, designed to maximize the chances that any subsequent evaluation will result in useful information.” (Which probably means I want to use them in a way for which it was not devised.)

I think the steps of the process that are most interesting to me, are the outcomes from Steps 6, 7 and 8.

6. Describe Stakeholder Perceptions of Program.
7. Identify Stakeholder Needs, Concerns, and Differences in Perceptions.  Differences in perception, needs, and concerns can indicate misperceptions of the program and intent, or a program that is not sufficiently meeting the needs of one or more stakeholder groups.
8. Determine Plausibility of Program Model.  Data from program staff, documentation, and stakeholder interviews are used to determine plausibility of the program.  That is, data are analyzed to determine the extent to which the program is properly implemented, sufficiently developed, and activities appropriate, to reasonably predict that desired outcomes will be met.

References

Leviton, L. C., & Gutman, M. A. (2010). Overview and rationale for the Systematic Screening and Assessment Method. In L. C. Leviton, L. Kettel Khan, & N. Dawkins (Eds.), The Systematic Screening and Assessment Method: Finding innovations worth evaluating. New Directions for Evaluation, 125, 7–31.

Trevisan, M. S. & Huang, Y. M. (2003). Evaluability assessment: a primer. Practical Assessment, Research & Evaluation, 8(20). Retrieved August 8, 2010 from http://PAREonline.net/getvn.asp?v=8&n=20

Wholey, J. S. (1979).  Evaluation:  Promise and performance. Washington, DC: The Urban Institute.

Source: Brandon/Microsoft Excel

Oh, this is where I add the chart title!

The answer…open the Formatting Palette from the View Menu.

I could change all sorts of formatting options by clicking on the chart or viewing the chart toolbar…but I couldn’t change all of them that way. To do that, I needed to open up the Formatting Palette.

Thanks again, Microsoft.

Peter and I decided not to migrate the individual sites now, pending a further investigation of how to handle the hostnames and Shibboleth integration.

For the purposes of this post, let’s assume the main site is accessible via http://oeit-tsa.mit.edu/ and the files are located in /var/www/oeit/ subdirectory on the server.

In no particular order:

• Converting OEIT’s existing WordPress blogs over to a single WordPress multisite install changes the type of administration needed to maintain the blogs. It shifts the burden to keep multiple instances of WordPress running and up-to-date to keeping a single instance of WordPress up-to-date, with the potential to affect all sites with a single update. So, if there are a small handful of sites, that are getting constant use, then maintaining them separately is less hassle than the migration. If the number of sites grow, or the sites administrative usage goes down, and there’s desire to keep them functioning, it’s better to move to a single multisite. Or, for example, OEIT gets in the business of hosting and supporting a limited network of sites for users across campus as some universities do (e.g, the University of British Columbia (1) or University of Mary Washington (2). There are some additional considerations in the consolidation that I’ll cover below.
• With a “Network” (WordPress’ term, I’ll also use the phrase “multisite”) of sites, there will be a main site and a number of network sites.
• The multisite version of WordPress wants to run in the document root of the main server. This means the main server name is pretty important from a branding perspective. Ideally the hostname would be oeit.mit.edu.
  

  The WordPress Codex on Create a Network says:

  • Giving WordPress its own directory will not work in WordPress 3.0 with multisite enabled. It interferes with the member blog lookup.
  • You cannot create a network in the following cases:
    • “WordPress address (URL)” is different from “Site address (URL)”.
    • “WordPress address (URL)” uses a port number other than ‘:80′, ‘:443′.

• Most of our work is done on virtual servers hosted by MIT’s IS&T. As part of that process they’ll configure the servers to a certain degree for us. When we request a new hostname, IS&T usually likes to give us individual IP addresses for each hostname. This means, that on our server oeit-tsa.mit.edu, we actually have a number of different IP addresses assigned as DNS A records. For example:
  

  spokenmedia.mit.edu. 3600 IN A 18.9.60.213

  However, running a multisite WordPress 3 (using sub-directories) instance implies that there is a single IP address for the server, and that the network of sites is accessed from the main hostname/IP address pair. This is a bit of a departure for us. There are two ways to address this…either change the DNS entries for the individual hostnames to the main server IP address and use the WordPress MU Domain Mapping plugin, or create and maintain custom Apache rewrite rules to take requests for http://spokemedia.mit.edu/ and resolve them to the site at http://oeit-tsa.mit.edu/spokenmedia (or vice versa, I couldn’t figure out which way to write this and not be confusing).

  In discussing things with Peter, we’re still not certain which way to go…and there’s an outstanding issue to consider.

• If we want to integrate with MIT’s Touchstone service via the Shibboleth plugins and server configuration, we may need to do Apache rewrites.
• WordPress 3 Multisite allows for centralization of the management of themes and plugins. This means there’s a single place to update both for all blogs in the network–and also one place to screw up all blogs in the network. It also implies that there is a single set of themes for all network sites. And, unless not restricted, a single set of plugins for use by all network sites. It is possible to either globally allow network site administrators to add site specific plugins or not–there doesn’t seem to be a great middle ground. One way around this is to have selected site admins also be Super Admins, they can then add plugins and activate them. This some site admins as super admins workaround works for the current (August 2010) usage of WordPress at OEIT.
• Our paid theme, Thesis 1.7, will require a customization to allow each site in the network to have it’s own custom variables for this theme.
  • http://www.binaryturf.com/using-thesis-theme-with-a-wordpress-multisite-installation/, make sure to scroll down to see how to do it with a blogId instead.
  • http://diythemes.com/forums/showthread.php?29799-New-Wordpress-3.0-features&highlight=multisite

Some good references:

• http://wordpress.org/extend/plugins/wordpress-mu-domain-mapping/
• http://www.wpwebhost.com/using-multiple-domains-with-wordpress-mu/
• http://ottopress.com/2010/wordpress-3-0-multisite-domain-mapping-tutorial/
• http://wordpress.org/support/forum/multisite
• http://wordpress.org/extend/plugins/network-privacy/ or http://wordpress.org/extend/plugins/more-privacy-options/
• http://codex.wordpress.org/Migrating_Multiple_Blogs_into_WordPress_3.0_Multisite

My preferred method is to run WordPress in a sub-directory of the Drupal installation.

So the server’s document root is set to: /var/www/html/oeit/. The Drupal instance is in: /var/www/html/oeit/drupal/. And the WordPress install is in /var/www/html/oeit/haiti-oer-symposium/.

Aside: We already have a rewrite rule in place because our Drupal installation was coded to require the subdirectory <server document root>/drupal. Yes, that’s not ideal. But the rewrite rule has been a heck of a lot easier than going through and changing the custom theme and testing it out. I’m not a Drupal developer, nor do I see a particular need to become one right now.

With the rewrite rule, I needed to be able to let the WordPress rewrite rules take precedence in the /var/www/html/oeit/haiti-oer-symposium/ directory. That actually gives part of a clue as to how the problem is solved.

I originally looked for stuff like “integrate wordpress and drupal” or “run wordpress in subdirectory of drupal”. Ultimately I ran across the suggestion to have Apache ignore anything going to the haiti-oer-symposium sub-directory.

I added the following code to our .htaccess file:

RewriteCond %{REQUEST_URI} !^/haiti-oer-symposium/


Here’s an explanation from rick_deckard about how this is doing it’s thing…

RewriteCond %{REQUEST_URI} !^blog

…

In that case it says
If the request URI does NOT (!) BEGIN (^) with “blog” and the requested URI does not map to a file or directory, then rewrite to invoke drupal.

Put another way
If the request URI is for my blog or a file or a directory, serve that straight up, without handing me off to drupal. So in the case of your blog, it passes you through to WP

…

[And this proved to be key...]

As for the leading slash – run the HTTP Live Headers plugin in Firefox to see what the server thinks your actual REQUEST_URI is (or use phpinfo() on your /blog directory). In my case at least, it does not want the leading slash.

[Our server did require the leading and trailing slashes.]

Source: rick_deckard

So, is it better to know what you’re doing, or just get lucky with copy and paste?