I ticked the wrong box

I’ve spent the last hour or so trying various things out to get passenger and PHP to play nicely together on my mac under OS X (Leopard) and apache2.

The situation I was finding was that PHP apps would run, but only if you explicitly call the script (ie index.php) rather than just the directory. If you called the directory, passenger would take over and give me a rails routing error.

The issue was to do with the passenger vhosts configuration. On my machine I have an number of ruby on rails apps configured with the passenger preferences pane (creating vhost entries within /private/etc/apache2/passenger_pane_vhosts/. I have enabled user_dirs, so that the users of my machine’s pages (and other apps) are served from their ~username/Sites directory.

My users configuration info for apache is installed in /private/etc/apache2/users/, and the instructions to load the configuration from that directory is stored within /private/etc/apache2/extra/httpd-userdir.conf (content below).

# Settings for user home directories
#
# Required module: mod_userdir
#
# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received.  Note that you must also set
# the default access control for these directories, as in the example below.
#
UserDir Sites
#
# Users might not be in /Users/*/Sites, so use user-specific config files.
#
Include /private/etc/apache2/users/*.conf

To get everything working together nicely, I merely wrapped this inside a vhosts configuration directive, and gave it a ServerName of localhost – so that this vhost would be the one that responds to requests for localhost, rather than some random passenger vhost assuming it was the boss of everything. New /private/etc/apache2/extra/httpd-userdir.conf below.

<VirtualHost *:80>
  ServerName localhost
  UserDir Sites
  Include /private/etc/apache2/users/*.conf
</VirtualHost>

Thanks to this, all of my rails apps are served under passenger, and I can have static HTML, PHP and camping apps (previously configured – nothing to do with the above) all served from within my ~username/Sites directory.

Hope this helps someone.

The recent deal announced between Microsoft and Yahoo strikes me as odd.

I understand that they are looking to create a competitor to Google in both search and advertising, but the “price paid” seems very high – at least on the part of Yahoo.

Major terms of the deal:

• Microsoft will be powering Yahoo search
• Microsoft have licensed Yahoo’s search technology for 10(!) years
• Microsoft will run paid search via their search engine
• Yahoo will be providing the advertising sales force for their combined “paid search” capability
• Each company will still maintain separate advertising sales forces for other advertising
• They enter a revenue sharing agreement, but Microsoft guarantee Yahoo will get at least existing revenues for the next 18 months
• Microsoft pay most of its traffic acquisition costs

So, boiling it down, it appears Yahoo are giving up their search engine technologies (for at least 10 years) in conjunction for (at least current) revenues to be paid by Microsoft for algorithmic search advertising.

Microsoft have to maintain a sales force to sell other advertising, so they aren’t saving costs there. They are still having to maintain search so they aren’t saving costs there. They are paying Yahoo for traffic acquisition, and revenue for algorithmic search advertising, so they are losing money there. Their benefit seems to be

1. Acquisition of a license for Yahoo’s search technology – given they’ve just released their own shiny new engine, is this an asset or liability?
2. Traffic – this is what Microsoft are in the deal for for. Traffic from Yahoo.

10 years is a long time. Search changes a lot in 10 years. Google was only just starting out 10 years ago. Altavista (at least where I was using the web) was top dog back then. I’d be interested to see if Yahoo are going to maintain their search technology, or just let it die off. Is this a sign that they no longer want to compete in search, but be a destination that pulls together other properties (harking back to their very early days I guess). I guess time will tell if Yahoo’s apparent specialisation strategy was a sensible or dumb move. Microsoft are banking on Bing becoming a google killer, or at least a serious competitor, in the long term. They also apparently believe that paid search results are the way of the future – that’s why they want the traffic.

I went to look at the ESTA website today as my girlfriend needs to apply for one of these authorisations to be allowed to travel to the US.

The website was very intimidating, and confusing.

1. The URL – if you’re providing an online site that every traveller to the US has to visit to get an authorisation to travel my advice would be choose a URL that is easier to remember than https://esta.cbp.dhs.gov/
2. The warning message – one sure fire way to scare users is to show them a message that looks like this when they connect to the site
   
   
   Note: There is no expectation of privacy when you use this computer system
3. Make it doubly confusing by completely contradicting the previous message on a “Help” page within the site.
   
   Note: Is this Web site secure and private? Yes.

I had a very confusing situation today with a multipart form that was for uploading a picture to a new web service I’m working on.

In Safari the form upload worked. Even in Internet Explorer 6 the form upload worked (after I fixed the dodgy MIME-type that IE passes through for JPG images – image/pjpeg for those interested).

The form I was trying to submit had the multipart attribute set correctly, and also had some javascript to disable the file selection, form submission button, and show a spinner to indicate that something is happening, and they don’t try and submit the file twice if they’re sending in a large image.

My submit tag orginally looked like this (Ruby on Rails)

<%= submit_tag 'Upload Photo', :class => "formbutton", :id => "submit-button",  nClick => "$('upload-form').submit();Form.disable('upload-form');Effect.toggle('footnote', 'appear', {duration: 0});Effect.toggle('spinner', 'appear', {duration: 0});" %>

I was very confused as it did work in those other browsers, but not in Firefox.

The key to fixing this was to add return false; to the end of the javascript statement…

<%= submit_tag 'Upload Photo', :class => "formbutton", :id => "submit-button",  nClick => "$('upload-form').submit();Form.disable('upload-form');Effect.toggle('footnote', 'appear', {duration: 0});Effect.toggle('spinner', 'appear', {duration: 0});return false;" %>

What I find particularly confusing about this is that everything I read on the “return false;” statement leads me to believe that this form should not be submitted – however – return true does not work (500 Internal Server Error returned). But what the hey – it works.

I’ve recently transferred some funds internationally. To do this I needed a special account code so that the bank I’m sending money to know which of the accounts they hold should receive it. This number is a conventional looking account number, prefixed with a country code, and a checksum value. There is also a website that checks them – http://www.apacs.org.uk/payments_industry/ibans_5.html

Putting in a country that they can’t check the actual account number for causes their little javascript application to unleash a serious dissing.

Ouch!

BTW – Sorry for the Rodney Dangerfield knock-off quote. He’s awful.

me: Countees isn’t in google yet

someone else: You have to put it in there?

me: Yes, I have to tell them about it.

someone else: Don’t they just find it?

me: How would they find it?

someone else: Google.

 

 

BTW – check out countees.co.uk – wear your UK county on your chest.  More about this soon.

I got an email yesterday from Amazon.com about the Verve’s new album Forth.  They were offering me a free, DRM free download of their latest song “Love is Noise”.  Having not heard anything out of the Verve for a while I was interested, and free is a pretty good price so I went to download.

The first thing I was unimpressed with was the Amazon.com downloader they tried to install on my machine.  I understand that some people may not understand how to add MP3s to iTunes, but the “skip this step” link to me was not in an intuitive place.  So, I accidentally downloaded it, went back to the page, then found the skip link.

But the real kicker with this is the below screenshot.

Useless.   

Why would they send me an offer I can’t redeem, ESPECIALLY WHEN THEY KNOW THAT I DON’T LIVE IN THE US.  They have my address, I have purchased from them before.  Unimpressed.

Opening hours. I want them on every physical stores, restaurants, and bars website. They do good store locators in the UK, I guess it’s because postcodes are everywhere, everyone knows them and they identify a very small area (a street, or part of a street). How come stores, when thinking about the data on their store locator, don’t include opening hours. Address and phone are always there, but when I’m going home on the train I want to know if my local stores will still be open when I get there.

Oh well, no spending at that particular store tonight.

At the moment I’m working on a fairly complex extension for Radiant CMS. In creating the administrative pages I want to use a javascript library that is not distributed with the core radiant code. This post will describe how to implement your own extension that can use an external javascript library, without playing around with any of the core radiant files to inject the javascript into the administrative layout.

It’s actually really easy to do. If you haven’t created a Radiant extension before I’d recommend following this tutorial on the Radiant wiki.

Inside the Radiant GEM, the standard page layout resides at app/views/layouts/application.html.haml

The lines of code that insert the javascript tags are:

- @javascripts.uniq.each do |javascript|
  = javascript_include_tag javascript

The @javascripts variable is populated from inside the app/controllers/application_controller.rb file. The culprit is below.

def include_javascript(script)
  @javascripts << script
end

Pretty simple huh? So, all you need to do, is call this method from within your new controller, because all controllers inherit from the application_controller.rb file, so they have access to this method, and you can have different javascript included for each method if you so wish. In (assuming the example LinkRoll extension was built as linked above) vendor/extensions/link_roll/app/controllers/admin/links_controller.rb

def index
  include_javascript("admin/mootools-1.2-core-yc.js")
  @links = Link.find(:all)
end

That will insert a link to admin/mootools-1.2-core-yc.js inside the admin/links/index page. Righto, so now the only thing left to do is get the mootools-1.2-core-yc.js file into the actual public/javascripts/admin directory within the project. What you want to do is alter the vendor/extensions/link_roll/link_roll_extension.rb file so that within the activate method the file is copied over. I’d recommend making a public/javascripts/admin directory within your extension folder, and putting the file in there. Then, when activate is called on the link_roll_extension.rb file, the activate method will copy the file over to the projects public/javascripts/admin directory. You should also delete the file when the deactivate method is called in the link_roll_extension.rb file.

Questions and comments please!

This might be old news (released end of May, I’m soooo behind the times), but Google are supporting hosting for popular javascript libraries, and they are promoting people using their copies of the libraries rather than hosting their own.  I only just found this out, and I think it’s pretty cool

http://code.google.com/apis/ajaxlibs/

The service supports either programmatic inclusion using the google jsapi library, or linking directly to their hosted copies.

Good things about this

• You save bandwidth costs, as your users download the libraries from google
• Your users get faster browsing ON OTHER DOMAINS, because the more people that use a single source, the more caching should happen

Bad things about this

• Google have more opportunity to don’t be evil – the biggest concern for me is their increased ability to understanding which users use your application, and propensity for understanding how they use it.  A malicious individual within the company could put some nasty code in the js to screw with your site, or monitor and transmit back to googlebase what the user is up to.  It’s very unlikely, but it could happen.