DVI connector problem with 2008 Mac PowerBook and Video Projectors

I've got a 2008 metal Apple MacBook which has the new mini DisplayPort that allows you to connect an external monitor. Apple provide a mini-DisplayPort to DVI adapter and I use that all the time with my Viewsonic external monitor ... not a problem.

Last week I wanted to show a client some work I had done for them and so took the Mac, the mini-DisplayPort adapter and a DVI to VGA adapter with me. BIG PROBLEM... I needed the DVI-VGA adapter to connect to the client's projector. But when I tried to plug the Apple DVI-VGA adapter into the Apple DVI-DisplayPort adapter it wouldn't fit.

The DVI-VGA adapter has four extra pins on either side of the flat blade of the DVI plug. The DVI-DisplayPort adapter has no matching holes!!! What the!?!

It turns out there are more than one DVI connector. The new DVI-DisplayPort used the DVI-D connector - 'DVI Digital', also called True Digitial. The other adapter uses DVI-I - 'DVI Integrated Digital and Analog (and specifically the Single Link version thereof). You can plug DVI-D or DVI-I onto a DVI-I socket ... but not the other way round...

You get more of the gory details here: http://www.directron.com/dviguide.html - scroll down for images of the connectors.

So if you want to use your MacBook with a VGA projector, you need to get a suitable adapter.

You might want to go with a direct miniDisplayPort to VGA. Apple sell one for $29 (Mini DisplayPort to VGA Adapter) This will do the job but it is really overpriced considering what it is.

You could also get a DVI-D to VGA adapter. Apple have one of those but they don't say if it is DVI-D or DVI-I! What use is that? Your best bet is to look on Amazon and be specific about DVI-D. You want Male DVI-D and Female VGA. There are plenty of options.

One last thing - don't confuse mini DVI with mini DisplayPort - two different things!

In my meeting I was lucky - it wan an informal meeting and I was able to copy my files to a Win PC that connected to the projector. But if that had been an important presentation I would have looked like a fool... not good. Get an adapter TODAY.

A Rails, Ajax and RJS issue - seeing JavaScript in your HTML

Here's an example of the dangers of following tutorials too closely...

I want to use Ajax on a web page to monitor the completion of a job running on a remote server. For the purposes of this tip, all I want to do is change the text 'Running' to 'Completed'.

The div I want to update is called 'check_status_div' and starts out as:

<div id="check_status_div">Running</div>

Below it I have this block based on text in the Rails book:

<%= periodically_call_remote :url => { :action => 'check_status', :id => @job.id },
    :update => 'check_status_div'
    :frequency => 5,
    :condition => "$('check_status_div').innerHTML == 'Running'"
%>

This ought to call the 'check_status' action in the controller, every 5 seconds and update the div 'check_status_div' until that div no longer contains the content 'Running'

In the Controller I have this:

  def check_status
    @job = Job.find(params[:id])
    if @job.completed?
      render :update do |page|
        page.replace_html 'check_status_div', "Completed"
      end
    end
  end

This get the specified Job object, calls a method in the Model to determine if it is complete and, if so, replace the contents of the 'check_status_div' with the string 'Completed'.

To get this to work I also needed to add a custom route to routes.rb. Note that this is a POST.

map.resources :jobs, :member => { :check_status => :post }

That should work... but I get this:

try { Element.update("check_status_div", "Completed"); }
 catch (e) { alert('RJS error:\n\n' + e.toString()); 
alert('Element.update(\"check_status_div\", \"Completed\");'); throw e }

That's not right...

The problem turns out to be that I am duplicating the ID of the DIV to be updated, first in the 'periodically_call_remote' call in the view, and again in the controller. Leave the controller and remove this line from the Ajax call in the View:

    :update => 'check_status_div'

It works... I'm not quite sure why. All the 'try' verbage is the JavaScript returned from the server and with that 'update' clause in the ajax call this is not getting evaluated.

Hope that helps.

Switching an Email Server to Google Apps

I've been running my own email server on a machine on my network for years. It's been fine but I've never had a good handle on spam (and when your email address is jones then you get a lot of it!), when my DSL goes down so does my access to email and it's just one more thing to look after. Plus recently Hotmail and Yahoo have started treating email from servers behind DSL connections as spam... great...

So I've moved my email over to Google Apps. You can set up an individual account, of course, or you can sign up for their 'Premier' Edition at $50/user/year (which is not bad) or you can use their 'Standard' Edition for free with up to 50 users (and some ads). I went with the latter - here is how you do it:

Assumptions:
1: You have an existing domain name
2: You have an existing and operational mail server
3: You access that mail server from Thunderbird, etc, via IMAP

Note that Google does not promote the Standard Edition - but it is there and open to new subscribers. Go to this signup page.

There are three stages:
1: You set up the server on Google Apps and demonstrate that you own the domain
2: You change the DNS records so that your email gets sent to it.
3: You change you mail readers to access the mail on Google

I'm not going to go into all the details as Google's help pages are pretty good. but there are a few things to bear in mind and one really important thing.

Part 1

You can go ahead and set up the Google Apps account without messing with your existing email, at least to begin with. You need to demonstrate that you are the owner of the domain and they give you two ways to do that.

If you have a web server on this domain then you can create a web page called googlehostedservice.html which will include nothing more than a string that they provide - something like google5caf2f0c6ff7e39 - yours will be different. You place that on your site and Google will look for it and verify your control of the domain. This might take a little while - minutes, not hours.

You then need to create accounts for each user that the server will handle mail for. Note that they do not support regular email aliases, which was an issue for me. But you can create accounts for each alias and then forward email to another account. I haven't figured out all the options with it yet.

They give you a test email address that allows you to test things are working before you actually switch the DNS records.

Part 2

Now you switch the DNS records...

STOP RIGHT THERE !

Once you do this all your prior email on your server will NOT be available to you. It will still be there but unless you want to use an alternate domain name, you will not be able to access it via IMAP.

So right before you change DNS records you want to go into Thunderbird, or whatever, and select your entire Inbox (and other folders) and copy their contents to one more more Local Folders. This can take a while with large Inboxes.

I did not realize this until too late. I recovered by using an alternate domain name and pointing that to the old server, but if not for that I would have had to reset the DNS to the old server, get the existing mail and then redo the DNS changes.

OK... you've got your existing email stashed away. Now change the DNS MX records as directed by the Google instructions. It can take some time for those changes to propogate and until they do, new incoming emails will still be sent to the old server and so may not be accessible to you. So make the changes when things are fairly quiet.

On a Unix system you can see what the records point to with the command 'dig yourdomain.com mx'

Unless you want to use other Google Aps services, do not change other DNS records - only the MX records.

Part 3

At this point your email will be going to your account on Google. Login to the URL they gave you - something like https://mail.google.com/a/yourdomain.com/ - and try sending/receiving email. It should just work. If not then check those DNS records again and/or wait a while for them to propogate everywhere.

If the web interface to your email is working then reconfigure your email client to access the Google hosted server. Look at their instructions and follow them carefully. You need to change the incoming and outgoing server names to ones at Google and importantly you will need to change the ports that they use as these are not the defaults.


Overall, the change has worked well for me. Google is doing a good job handling spam, I can access the mail from anywhere, I can avoid the ads by using Thunderbird, and I can give up running my own server. It's a win all around. At some point I may upgrade to their premier edition but I don't see a real need to do that right now.

One less thing to worry about... and no, I don't worry about Google...