I wrote a web-crawler today for one of my other projects, and ran into the above problem “OpenSSL::SSL::SSLError: certificate verify failed”, well I was just collecting websites and didn’t really care about the validity of SSL certificates, so I just wanted a quick fix.

Here it is:

require ‘openssl’
OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE

Essentially, I just change the constant for VERIFY PEER to the Value of VERIFY NONE, pretty sneaky :-), and no real work required.

I don’t feel like rehashing the hours I spent today trying to get various methods of taking command line screen shots of web-pages to work, but I’ll pull out a few useful pointers here.

There are 2 ways of doing this for free. (That is, if you value your time at $0 an hour)

First: khtml2png

http://khtml2png.sourceforge.net

khtml2png2 can be installed via a debian package, and runs on any variant of linux, as long as you have KDE installed. I didn’t, and thus spent a long time downloading KDE. It uses Konquerer to render the webpages, and Konquerer will often prompt for user input when something is wrong (i.e. — a plugin is missing (FLASH), or the web site wants access to your cookies.) It also was incredibly slow on my relatively fast desktop machine. However, it does the job — alright, and fits the price — free.

Second: webkit2png

Unfortunately, I was determined to make this process a little bit faster, and spent about 4 hours trying to get http://www.paulhammond.org/webkit2png/ to work. Webkit2png will run on OSX and takes screenshots using WebKit. It is fast, and a pain in the ass to install if you are unlucky. You’ll need Python, and the PyObjC wrappers. It was trivial for me to setup the wrappers from http://pyobjc.sourceforge.net/. The whole process should be pretty straightforward, install PyObj, and grab the Python code from the above website, no problem. Of course on my computer WebKit the header files the PyObjC setup.py wanted could not be found, and because of this the PyObj was not generating some of the files that PyObjC needed to run, “_WebKit_Str.inc” in particular. I tried a few tricks to make the setup.py find these header files, and managed to completely screw up my webkit install. Long story short, the script that generates stub files for PYOBJC ONLY looks in /System/Library/Frameworks/ no matter what you specify in the setup.py, and doesn’t even look in /Library/Frameworks even though it is listed in the default setup.py.

For PYOBJC to install correctly, you must have a directory called WebKit.framework in /System/Library/Frameworks, and it MUST have a Headers directory inside of it. And these headers must match the binary version of the WebKit library. I.e. you should have a directory structure that looks like:

bcx-mbp:/System/Library/Frameworks/WebKit.framework root# ls -l
total 24
lrwxr-xr-x    1 root  wheel    27 Jun  3 23:29 Frameworks -> Versions/Current/Frameworks
drwxr-xr-x   42 root  wheel  1428 Jun  3 23:40 Headers
lrwxr-xr-x    1 root  wheel    26 Jun  3 23:29 Resources -> Versions/Current/Resources
drwxr-xr-x    4 root  wheel   136 Jun  3 23:21 Versions
lrwxr-xr-x    1 root  wheel    23 Jun  3 23:29 WebKit -> Versions/Current/WebKit
bcx-mbp:/System/Library/Frameworks/WebKit.framework root#

The problem that I faced, and caused me to waste so much time was that I was missing the Headers directory inside of /System/Library/Frameworks/WebKit.framework. To solve this problem you can try doing a find -name WebKit.h and copying the Headers directory containing this file into your WebKit.framework directory. In my case I had another copy of the WebKit headers at: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/WebKit.framework . Copying the headers directory from the above directory did the trick.

Now I left out a lot of the indirection that I faced in solving this problem. At some point in this process I broke WebKit and had to installed the 3.1.1 Safari upgrade from apple, (As described by: http://soakedandsoaped.com/articles/read/how-to-fix-broken-webkit-framework-after-safari-3-1-upgrade ) which updated my WebKit binary, but did not give me header files. Luckily the header files from the above /Developer/SDKs/ worked with this new WebKit binary. However the WebKit binary located in /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/WebKit.framework did not work with my version of Safari, and still gave me errors when I tried to load it using import WebKit in the python code I was testing. In short, I managed to get everything working, and I believe the root of my problem was a missing Headers directory, but I might have also needed to install Safari to fix issues with my existing WebKit install so that I could install and compile PYOBJC with WebKit bindings.

It is likely that all of these problems are fixed on Leopard, so it’s unlikely anyone else will run into these problems. I believe Leopard comes with PYOBJC preinstalled, so no worries linking the two.

So anyway I got it all working and it was worth it, webkit2png.py is far superior to the konquerer based khtml2png2 even though it was a real pain to configure on Tiger.

I guess this is a little off topic.

Firebug wasn’t working and upon trying to uninstall it the add ons window would say that the change would be made after upon restarting firefox, even after closing all firefox windows and restarting.

This was fixed upon removing the applications.rdf:

rm ./.mozilla/firefox/g4cuxbnz.default/extensions.rdf

I just got my hands on a few motes and a Crossbow Stargate Netbridge (runs debian!) to manage them all. It’s too late in the day to really explain motes, but in the simplest sense they are little wireless sensors that can be theoretically be combined to form a wireless sensor network. The CrossBow Netbridge serves as a bridge between the (Zigbee?) Motes and a normal TC/IP network — Xserve is what they call their bridge/server application.

In any case out of the box they come with a nice management console Mote Explorer, which let’s you view data from the motes, graph it, and.. that’s about it, — although it does have a pretty slick Flash/Flex interface. Stanza ( http://www.stanza.co.uk/emergentcity/?tag=motes ) has written pretty extensively on his trouble using motes, I sent him an email requesting source code — as it is really hard to find any meaningful source code that uses both motes, and the Xserve (especially because of Apple’s Xserve).

Apparently there is some method of reading the current status of MOTES, or at least tapping into a MOTE sensor feed using the Xserve’s sensor bridge. It appears that you can make XMLRPC calls to the Crossbox Xserve, but these XMLRPC calls are not over standard HTTP (like normal XMLRPC) and require you to write your own custom client. It doesn’t look that hard to do, but I couldn’t actually find an XMLRPC call to read values from a sensor, so decided it wasn’t worth it to write CrossBow Python XMLRPC libraries.

Long story short I found another place to hook into the mote sensor feeds that is very easy to implement, and pretty clean. [ I am sure there is a nice way to accomplish this using XSERVE, but there documentation includes no examples, and thus is not -- quick hack friendly]

So here’s the trick. We get the sensor feed directly from the XSERVE console. (I think I may also be using an older version of XSERVE, they might have a newer edition now I am using 2.4.10)

We SSH as too to the StarGate and create a FIFO to handle the console output from the XSERVE

ssh root@____
mkfifo /tmp/mote_feed
chmod 777 /tmp/mote_feed


Then we create our own little startup script for XSERVE that will write to our FIFO

export LD_LIBRARY_PATH=/usr/xserve/bin
export XSERVE_PARAMETER_FILE=/usr/xserve/xparams.properties
export XSERVE_ARGS_FILE=/usr/xserve/xparams.args
/usr/xserve/bin/xserve  -u=user -s=/dev/ttyUSB1 > /tmp/mote_feed

Finally we write a quick parser for the output from the log file that can be dropped into another piece of code to send the data to a remote server, or do whatever you plan on doing with the data. The below parser is sort of ugly, but gets the job done. I prefer ruby or perl for parsing, but Python will get the job done.

#!/usr/bin/python2.5
import re
f = open("/tmp/mote_feed")
try:
  a = "q"
  good_entry = False
  item = {}
  while( a != ''):
    a = f.readline()
    if( re.search("^\[", a)):
      good_entry = False
      # print the entry I suppose
      if(item != {}):
        print item
      item = {}
    if(good_entry):
      if(a.find(":")):
        #print a
        d = a.split(":")
        #print d
        if(len(d) > 1 and d[1] !=”):
          if(d[0].strip(”\t\n “) == “health”):
            d[1] = d[1].replace(”parent=0″,”")
            d[0] = “node”
          item[d[0].strip(”\t\n “)] = re.sub(”[^\d\.]“,”", d[1].strip(”\t\n “))
      #print a
    if( re.search(”^\[[^\]]+\] MTS”, a)):
      good_entry = True
finally:
  f.close()

The Resulting output looks like:

{’node’: ‘272′, ‘battery’: ‘438′, ‘mic’: ‘438′, ‘light’: ‘756′}
{’node’: ‘272′, ‘battery’: ‘2.859251′, ‘mic’: ‘438′, ‘light’: ‘2112′}
{’node’: ‘272′, ‘battery’: ‘438′, ‘mic’: ‘437′, ‘light’: ‘757′}
{’node’: ‘272′, ‘battery’: ‘2.859251′, ‘mic’: ‘437′, ‘light’: ‘2115′}
{’node’: ‘272′, ‘battery’: ‘438′, ‘mic’: ‘438′, ‘light’: ‘757′}
{’node’: ‘272′, ‘battery’: ‘2.859251′, ‘mic’: ‘438′, ‘light’: ‘2115′}


Before parsing the data appears in the below format. So the batter level is in Volts?, temperature in degrees centigrade, light in mV ??, and microphone is in ‘counts??’. I also have no idea why the battery level is fluctuating between 438 and 2.859 — and light is fluctuating between 757 and 2115. It seems like there is some sort of error with the sensors, because it’s not with the parsing.

battery: = 2.859251 V
temperature=25.436247 degC
light: = 2112 mV
mic: = 437 counts


GZip’d format

http://projects.si.umich.edu/coolapps/coolapps.tar.gz

I finished working on porting the ever-so-popular nearby application for the public display to use the PHP API. You can see the code in action at http://display2.be-n.com/~hung/nearby.php and see the code itself at http://display2.be-n.com/~hung/nearby.php.txt

If you only see SI North, that’s because no one is near the screen.

It’s pretty sparse, but the API is now on the blog, in their own separate pages:

http://situated.wordpress.com/situated-php-api/

http://www.movino.org/application/mobile

A really cool application that captures video using your phone and sends it to your desktop computer, turns your N95 into a portable wireless video camera.

A week late, but here they are!

“http://blogsearch.google.com/blogsearch?hl=en&safe=off&client=firefox-a&um=1&ie=UTF-8&q=wide+angle+webcam&sa=N&start=0“

A google blog search, reveals a few companies making cameras with 80 degree optical fields of view.  Mouly’s selected camera has 200degree (range of view), and a ~78-76 degree optical field of view.