Tuesday, January 30, 2007
Sunday, September 10, 2006
Tuesday, December 06, 2005
Wednesday, November 30, 2005
Flock Browser
Been having a play with this new Flock browser which is supposed to be very good at integrating with RSS feeds and weblogs etc. It seems to be closely linked in with del.icio.us and that allows you to create your own account with a public web page containing your favourite feeds. See mine here. That's all quite fun, and it reminds me of the Start.com rich user interface which similarly allows you to create a sort of portal of RSS feeds.
If you browse from within Flock, it's a one-button click to add a new feed to your own del.icio.us account and therefore to your portal page.
If you browse from within Flock, it's a one-button click to add a new feed to your own del.icio.us account and therefore to your portal page.
Labels: web
Wednesday, November 23, 2005
Developer toolbar for Firefox
Here's a good toolbar, found this very useful...
http://chrispederick.com/work/webdeveloper/
http://chrispederick.com/work/webdeveloper/
Labels: web
Humans v. Computers
Amazon's Mechanical Turk API - named after a fake 18th Century chess-playing robot - reportedly allows you to submit tasks from a piece of software to a real human being. You just call a method containing the "HIT" (Human Intelligence Task) you want fulfilling, and then at some point in the future an answer comes back. The caller can specify what sort of a human being should be used to fulfil the task.
It's a fascinating idea: they call it "Artifical Artificial Intelligence" - i.e. it looks like you are sending a request to something artificial, but the fact that it looks artificial is artificial: it's actually human.
This is quite like Google Answers, where you can pose a question to some remote expert and, for a fee, get back a reply, although the Amazon product (on an initial look) seems to be geared towards fulfilling tasks that any human could do. The example they give is that you pass a photo into a particular method (e.g. isHumanImage()), and the Mechanical Turk returns true or false depending on whether the photo contains an image of a person.
I wonder where all this is going. I instantly picture an oppressed underclass, like something out of a Fritz Lang movie, lined up at desks fulfilling tasks sent to them by an anonymous internet robot, their exact performance monitored closely by whip-wielding capitalists who take a big cut of the fee...
The other thing that occurs to me is that it raises the question of objectivity. If you send a photo of Adolf Hitler with the question "is this human?" then wouldn't there be a tendency for some human agents to respond "false"? Or if you sent the question "is this a country?" with the argument "Palestine": the answer might depend on the responder's political views. Only by being totally strict about how to interpret the question (e.g. "is this name on the list of countries or not?") could you avoid the tendency for humans to do slightly unpredictable things, but if you were doing that, why not just get a computer to answer the question anyway?
Questions that rely on human interpretation of sense data (e.g. "is this a picture of a human face?") would probably get the objectively correct response, more reliably than just having software scan the given image, but it would be interesting to see how value judgements can be avoided. The Wikipedia knows all about the dangers of articles surfacing on its site which are represented as "factual" but are actually "arguable": they have a system of flagging articles which are disputed.
It'll be interesting to see how the semantic web (as it emerges) deals with validity and how truth can be represented as relative as well as the traditional computing concept of "Boolean" truth.
It's a fascinating idea: they call it "Artifical Artificial Intelligence" - i.e. it looks like you are sending a request to something artificial, but the fact that it looks artificial is artificial: it's actually human.
This is quite like Google Answers, where you can pose a question to some remote expert and, for a fee, get back a reply, although the Amazon product (on an initial look) seems to be geared towards fulfilling tasks that any human could do. The example they give is that you pass a photo into a particular method (e.g. isHumanImage()), and the Mechanical Turk returns true or false depending on whether the photo contains an image of a person.
I wonder where all this is going. I instantly picture an oppressed underclass, like something out of a Fritz Lang movie, lined up at desks fulfilling tasks sent to them by an anonymous internet robot, their exact performance monitored closely by whip-wielding capitalists who take a big cut of the fee...
The other thing that occurs to me is that it raises the question of objectivity. If you send a photo of Adolf Hitler with the question "is this human?" then wouldn't there be a tendency for some human agents to respond "false"? Or if you sent the question "is this a country?" with the argument "Palestine": the answer might depend on the responder's political views. Only by being totally strict about how to interpret the question (e.g. "is this name on the list of countries or not?") could you avoid the tendency for humans to do slightly unpredictable things, but if you were doing that, why not just get a computer to answer the question anyway?
Questions that rely on human interpretation of sense data (e.g. "is this a picture of a human face?") would probably get the objectively correct response, more reliably than just having software scan the given image, but it would be interesting to see how value judgements can be avoided. The Wikipedia knows all about the dangers of articles surfacing on its site which are represented as "factual" but are actually "arguable": they have a system of flagging articles which are disputed.
It'll be interesting to see how the semantic web (as it emerges) deals with validity and how truth can be represented as relative as well as the traditional computing concept of "Boolean" truth.
Labels: web
Tuesday, October 11, 2005
Mambo Admin Interface (again!)
I think I've at last stumbled across the solution for the Mambo admin login problem, on this forum page.
It seems to be working better for me now anyway.
It involves adding an extra line in the includes/mambo.php script. In my case, it had to be
session_save_path("/homeb/s2/www/jeannot.uklinux.net/tmp");
I assume that's right anyway... i.e. the full path of my web space - gotta remember to change this if I move host or upgrade Mambo!
It seems to be working better for me now anyway.
It involves adding an extra line in the includes/mambo.php script. In my case, it had to be
session_save_path("/homeb/s2/www/jeannot.uklinux.net/tmp");
I assume that's right anyway... i.e. the full path of my web space - gotta remember to change this if I move host or upgrade Mambo!
Labels: web
Monday, October 10, 2005
Mambo Admin Interface
I kept running into problems with trying to navigate the admin interface - it would keep presenting me with the login screen again. There are various posts on the Mambo boards about this, and it seems to be down to either:
1. PHP config,
2. Apache config,
3. browser config
or 4. something else.
Which narrows it right down.
Anyway, when I use Firefox to browse the admin site, it seems to happen a hell of a lot less than with IE!
1. PHP config,
2. Apache config,
3. browser config
or 4. something else.
Which narrows it right down.
Anyway, when I use Firefox to browse the admin site, it seems to happen a hell of a lot less than with IE!
Labels: web
Thursday, September 29, 2005
MediaWiki
I'm still to-ing and fro-ing about CMSes. On the one hand I wanted something lightweight and easy to use, and I wanted something Java-y (since I'm a Java bigot), so Magnolia is good but you need to deploy in a J2EE container, which I might not want to when it comes to actually paying for hosting, so then you go back to LAMP solutions, but Mambo, although excellent in so many ways, and with such a big following, just seems a bit ponderous and feature-bloated to be worthwhile for the stripped-down site I have in mind. And also I keep running into problems with the admin interface requiring logins the whole time, that I never (bothered) getting to the bottom of.
So why not go for a Wiki solution? And if going for a wiki, go for the big one, the one that powers the Wikipedia itself: MediaWiki.
So I did. Download the tar.gz, drop the extract into my PHP-enabled Apache directory, run the config utility, (having ironed out the old-password problem in my MySQL installation, which I've run into before but had forgotten about), and there it is. Really pretty easy.
Now to have a play with it... or alternatively do some real work. Which is it to be?... Hmmmm............
Later:
Did I say "Really pretty easy" above? I think I did. Spoke too soon. I got the Main Page up in very short time, then spent the rest of the morning scratching my head over why some other wiki-generated pages weren't appearing. I was getting just "blank pages". The Apache access.log would tell me that a page had been served, but I could see items in the error.log saying "Filename is not valid". I thought it might be because of a colon in the URLs that MediaWiki generates (I am running Apache on Windows), but couldn't figure it. The help site says I should use mod_rewrite, which I thought I did, but got increasingly confused, started tweaking Apache settings, PHP settings, MediaWiki settings until I got into a right old you know what. Bleh. Almost binned the whole idea in desperation.
Finally resorted to changing my browser to use HTTP 1.0 instead of 1.1 "just to see what would happen" and to my surprise I started seeing a whole bunch of compressed-looking text, and some PHP error messages at the bottom, saying that it couldn't find my php/sessiondata directory. First I'd heard of that, but I suppose it makes sense that MediaWiki will use session facilities... I created the sessiondata directory in c:\php and it seems to be working OK now. Reverted the browser HTTP settings to default - have left the Apache settings as they are, so I don't know if that will turn round and bite me again sometime... but I've done enough for now. I need a cuppa tea. I shouldn't even be doing this anyway.
So why not go for a Wiki solution? And if going for a wiki, go for the big one, the one that powers the Wikipedia itself: MediaWiki.
So I did. Download the tar.gz, drop the extract into my PHP-enabled Apache directory, run the config utility, (having ironed out the old-password problem in my MySQL installation, which I've run into before but had forgotten about), and there it is. Really pretty easy.
Now to have a play with it... or alternatively do some real work. Which is it to be?... Hmmmm............
Later:
Did I say "Really pretty easy" above? I think I did. Spoke too soon. I got the Main Page up in very short time, then spent the rest of the morning scratching my head over why some other wiki-generated pages weren't appearing. I was getting just "blank pages". The Apache access.log would tell me that a page had been served, but I could see items in the error.log saying "Filename is not valid". I thought it might be because of a colon in the URLs that MediaWiki generates (I am running Apache on Windows), but couldn't figure it. The help site says I should use mod_rewrite, which I thought I did, but got increasingly confused, started tweaking Apache settings, PHP settings, MediaWiki settings until I got into a right old you know what. Bleh. Almost binned the whole idea in desperation.
Finally resorted to changing my browser to use HTTP 1.0 instead of 1.1 "just to see what would happen" and to my surprise I started seeing a whole bunch of compressed-looking text, and some PHP error messages at the bottom, saying that it couldn't find my php/sessiondata directory. First I'd heard of that, but I suppose it makes sense that MediaWiki will use session facilities... I created the sessiondata directory in c:\php and it seems to be working OK now. Reverted the browser HTTP settings to default - have left the Apache settings as they are, so I don't know if that will turn round and bite me again sometime... but I've done enough for now. I need a cuppa tea. I shouldn't even be doing this anyway.
Labels: web
Thursday, November 25, 2004
Mambo static content
First off, I think you shouldn't underestimate these LAMP(Linux, Apache, MySQL, PHP)-based software packages. Ideally I prefer working with Java, it's more scaleable, international (supports Unicode natively etc.), more object-focused, but for small things like these projects I'm working on at the moment, something like Mambo is just fine.
Anyway, I wanted to comment on something specific, for my own notes. Will be boring for everyone else, so I suggest you read something more interesting, for example.
Still here? OK. Must mean that you have a vested interest in reading about my tribulations with the Mambo install from directory feature! Here we are: I have tried to install the Mambo component for managing static content, because I wanted to have some documents/files on my site that would be accessible by URL but would not be intercepted by Mambo. If I tried to hit any static pages, it always got grabbed by Mambo which then served up the homepage. There is a component for Mambo called Static Content, which appears to work OK on my own server, but when I try to install from directory on my hosted server, it fails. I can't do an upload to my current hosted server as this is disabled by the administrator, and I cannot get install from directory to work either. There are various postings on the web about Mambo install from directory not working properly, but no solutions to it as far as I can see.
So I went down a different tack and changed the Apache .htaccess file to intercept GETs for my static documents (my CV in this case, which I have stored under docs/cv.doc), and serve that up anyway, thereby bypassing Mambo. Seems to work OK.
I can then make that URL a Mambo menu item by creating a new menu item with type "Link - URL" and then pointing at the static doc. So there you go.
Anyway, I wanted to comment on something specific, for my own notes. Will be boring for everyone else, so I suggest you read something more interesting, for example.
Still here? OK. Must mean that you have a vested interest in reading about my tribulations with the Mambo install from directory feature! Here we are: I have tried to install the Mambo component for managing static content, because I wanted to have some documents/files on my site that would be accessible by URL but would not be intercepted by Mambo. If I tried to hit any static pages, it always got grabbed by Mambo which then served up the homepage. There is a component for Mambo called Static Content, which appears to work OK on my own server, but when I try to install from directory on my hosted server, it fails. I can't do an upload to my current hosted server as this is disabled by the administrator, and I cannot get install from directory to work either. There are various postings on the web about Mambo install from directory not working properly, but no solutions to it as far as I can see.
So I went down a different tack and changed the Apache .htaccess file to intercept GETs for my static documents (my CV in this case, which I have stored under docs/cv.doc), and serve that up anyway, thereby bypassing Mambo. Seems to work OK.
I can then make that URL a Mambo menu item by creating a new menu item with type "Link - URL" and then pointing at the static doc. So there you go.
Labels: web
Monday, August 18, 2003
Web Applications
Back on the webapp route at work now, for a bit. Having major problems understanding why Tomcat can't find my ApplicationResources.properties file when it's in the WEB-INF/classes directory. Have tried it in various other possible places too - no joy. Finally I tried adding debugging info to see where the Java class was looking - and it's in C:\jakarta-tomcat-4.1.27\bin - WHY??? Putting the properties file there is no problem.
Am I missing out on something fundamental here???
Back on the webapp route at work now, for a bit. Having major problems understanding why Tomcat can't find my ApplicationResources.properties file when it's in the WEB-INF/classes directory. Have tried it in various other possible places too - no joy. Finally I tried adding debugging info to see where the Java class was looking - and it's in C:\jakarta-tomcat-4.1.27\bin - WHY??? Putting the properties file there is no problem.
Am I missing out on something fundamental here???

