Matt: August 2007 Archives

If you use MySQL, note this:


mysql> create database test;
Query OK, 1 row affected (0.01 sec)

mysql> use test;
Database changed
mysql> create table foo (
-> x int,
-> y int
-> );
Query OK, 0 rows affected (0.00 sec)

mysql> insert into foo values (1, 2);
Query OK, 1 row affected (0.00 sec)

mysql> select * from foo;
+------+------+
| x | y |
+------+------+
| 1 | 2 |
+------+------+
1 row in set (0.00 sec)

mysql> update foo set x=5,y=10,x=x+y;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from foo;
+------+------+
| x | y |
+------+------+
| 15 | 10 |
+------+------+
1 row in set (0.00 sec)

mysql>

I bolded the part that bothers me. No warnings. Double-updating the same value in the same row in the same statement throws no warnings (never mind errors!). I haven't checked the ANSI standard to see if this is mentioned, but it sure is worth noting.

I have an iPhone. I'm finding myself very prone to snapping photos now, whereas before I was completely unlikely to tote a camera. I also discovered that Movable Type works just fine on the iPhone, I even posted an entry on my personal blog from it while we were at the ice cream place.

But you know what? I want to put up a photo I just blogged. But transferring a photo via anything but email is a pain. Enter perl. I whipped up a perl script to receive iphone photo email, piped via procmail, and save the photo attachment to a path, then email back the phone address with the filename it used. Just make sure you set the path in the script to somewhere down from your DocumentRoot, and then you can immediately reference the photo with an img tag.

Now I can photoblog directly from the phone, which is pretty fun.

Requires
sendmail (for the outbound msg, but I bet you could adapt any other mail program)
perl
MIME::Parser
procmail

Here's the relevent part of my procmail entry (note that photoblog is an alias that goes to my user account via /etc/aliases):

:0H
* ^TO.*photoblog@ender.com
|/home/matt/iphotoparse.pl

And the code, which you can get here: iphotoparse.pl

Happy photoblogging from the phone.

iPhone, glorious iPhone

| | Comments (0) | TrackBacks (0)

i has a iphone?

It's true. I'm one of the converted. (Fallen?)

I definitely like it so far, although I was unimpressed with battery the first day. It really should be engineered to survive one day of hard use. I was charging it until late last night. I watched youtube from it in bed for about 30 minutes, had a total of 14 hrs of standby, and then about 6 or so hours of use (mostly as an ipod, small bit of phone). It died while I was talking to my wife en route home.

Rumor has it that bluetooth, and the "prompt" wlan networks features both suck up a lot of bandwidth, so I may try to keep those off when possible. (I'm going to turn bluetooth off while driving, damnit, but I don't really need it otherwise).

dojo.lang.hitch

| | Comments (0) | TrackBacks (0)

A few weeks ago, I was wrestling with one of those things that I used to consider a major pain with javascript: meshing objects and event handling.

Let's say you have some code. Sloppy, but demonstrative:

<html>
<head>
<script lanugage='Javascript' src='dojo/dojo.js'></script>
<script>
dojo.require("dojo.lang.*");
</script>
</head>
<body>
<div id='output' name='output'></div>
<script language='Javascript'>
function foo() {
var x;
var y;
this.go = function() {document.getElementById('output').innerHTML += 'this.x is ' + this.x + '<br />';}
}
var fooz = new foo;
fooz.x = 5;
document.getElementById('output').innerHTML += 'fooz.x is ' + fooz.x + '<br />';
setTimeout(fooz.go, 300);
</script>
</body>
</html>

What happens when you run it?

fooz.x is 5 this.x is undefined

Javascript objects do not stay instantiated when passed into setTimeout. setTimeout() is unavoidable, but I often find that when implementing behaviors which need objects, you're forced into one of two nasty choices:

  • Give everything an id, and pass that id into setTimeout in order to maintain some sort of scope
  • Watch everything lose context when passing through setTimeout

Not pretty choices.

But dojo.hang.hitch() solves that problem, gloriously. dojo.lang.hitch lets you attach a function to run IN THE SCOPE of an object.

Let's change the code above:

<html>
<head>
<script lanugage='Javascript' src='dojo/dojo.js'></script>
<script>
dojo.require("dojo.lang.*");
</script>
</head>
<body>
<div id='output' name='output'></div>
<script language='Javascript'>
function foo() {
var x;
var y;
this.go = function() {document.getElementById('output').innerHTML += 'this.x is ' + this.x + '<br />';}
}
var fooz = new foo;
fooz.x = 5;
document.getElementById('output').innerHTML += 'fooz.x is ' + fooz.x + '<br />';
setTimeout(dojo.lang.hitch(fooz, fooz.go), 300);
</script>
</body>
</html>

Output now:

fooz.x is 5
this.x is 5

Beautiful.

What's great is that this lets you run events on things without IDs. I dynamically instantiate a lot of elements in the DOM with document.createElement, and there's often no NEED to assign an id except for issues like this; handling events. Now, with DOJO's hitching, you can deal with your objects while preserving context through setTimeout calls.

Dojo is filled with gems.

Check out the Dojo Homepage and this little into to dojo isn't bad either.

September 2010

Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Creative Commons License
This weblog is licensed under a Creative Commons License.