Ian Lewis' Blog

If you are an e-mail admin you probably know about this already but ordb.org has started blacklisting all IP addresses. Ordb is a spam database that stopped operation a little over a year ago but remained in the configuration of many mail servers around the internet and in the default config of at least one MTA.

After stopping service they simply timed out but on March 26th they started blacklisting all IPs. I suppose this was a half brained effort to get people to stop trying to connect to the service but it unfortunately caused a number of MTAs to start blocking all incoming mail. Perhaps people should stay on top of news as it has been over a year since the service stopped but blocking all IPs seems like a strange solution.

Mercurial is a nice distributed SCM system written in python which I have been using at work and at on oss projects for a little while now. Mercurial allows three types of branching, cloning, named branches, and local branches. Each of these has it's uses but I have only really used cloning and named branches in my own development.

Cloning simply allows you to create a new branch of a repository by creating a copy of it. Simple. You make a copy of the repo, make changes in that copy, and you can merge the changes back into the original branch using push or merge changes in the original into your copy using pull. This is by far the simplest way to do branching. Each branch is self contained and easily managed/copied/deleted (which may or may not be a good thing depending on how you see things).

Named branches are branches that live in the same repo. You can create a new branch make a commit, and switch back to the original branch all within the same repo. This is achieved using the branch command in mercurial. You can switch your branch like so:

hg branch mybranch

Here we just created a branch off of the current version and called it 'mybranch'. Now if we make a change and commit it this change will be marked as part of our new branch. This is kind of nice because we can switch between branches quickly and easily. Also, long lived branches can be split off within the same repo and merged easily using the merge command. You can switch between branches by updating your local repo with the following command:

hg update -C mybranch 

This command figures out what changes need to be removed and what needs to be added to get you to the HEAD of the another branch.

Unfortunately, this is where the good things about named branches end. Named branches live in the same repository so you can't selectively push or pull changes. So if you have a bunch of changes in your main branch that are ready for pushing to your shared repo, but you have a named branch full of changes that aren't ready to see the light of day, you can't selectively push the stuff in your main branch without pushing the stuff in your test branch. This is a big problem because it can clutter up your shared repo.

Also, the hgweb and hgwebdir cgi scripts that show you changes to your repository in a easy to understand way simply fail to break changes out by named branch. This was the biggest problem for me because I lost track of what changes I had put in what branch so I had trouble compiling all the changes I wanted to for a release. I really wanted to look at the web interface and see the changelog for a particular branch but the hgweb interface simply shows all changesets in chronological order regardless of what branch you clicked on. It also doesn't show what branch a change was commited to so it's impossible to find out where a particular change was commited without looking at the parent changeset and backtracking to where it was split off from the main branch (this is not reasonably achievable.

Named branches are also not deletable. Meaning once you figure out all of the downsides of using them your repository is already full of these named branches and you can't delete them. This also exasperates the push problem because you might push some changes in a test branch to a shared repo inadvertently but once you realize this the damage is already done because you can't delete the branch from the shared repo without backing out all of the changes you made, nor can you delete them from your local repo and then push, or selectively push only one named branch. Basically you're stuck with them forever.

This is probably why there has been talk on the Mercurial mailing list this month about fixing named branches and recommending that developers not use them until they are.

I came across this website called Zoho which has a lot of interesting web apps like Google's web apps. Google has Google docs, spreadsheets, and presentations. Zoho has docs, spreadsheets, and presentations. Google has Google notebook. Zoho has a notebook. Google has gmail. Zoho has Zoho mail. Google has... well you get the idea.

All that stuff is well and good but the thing that caught my eye was the Zoho creator and the Zoho DB & Reports. Granted, Google has it's own things like a neat little chart api(on the right) but nothing like Zoho's DB and integrated report creator that I know of. Google Base seems built for an entirely different purpose. Granted that the Zoho DB and Reports are not going to rival any enterprise reporting software but would provide you with an easy to use reporting tool for small to <the step above small (not medium)> sized databases.

Anyway, the possibilities seemed interesting for an online set of integrated applications like Zoho has. Especially the DB, App creator, and Spreadsheets but I'm sure you could think of powerful ways to integrate the other things like TODO and e-mail. The problem is that Zoho hasn't integrated these (yet?). The Zoho creator, though billed as a way to "Create Database Applications", is not integrated with the DB. When you create an app, and with it, a form and a view in the creator, the database and tables don't show up in the database app. *scratches head* Isn't integrating these two obvious? It would be cool to have an application with a database that you could then load in Zoho Database and create reports etc. But alas, the creator is a stand alone.

The integration issues combined with bugs in the creator when saving data, when saving text other than english, and when accessing using a Japanese phone, all are pretty much show-stoppers for me using it. It seems like it's so close, but missing some critical pieces. They may be adhering to the release early, release often philosophy and they are definitely sticking to the "release early" part. I just hope they stick to the "release often" part.

Recently I read an article on gyaku that says that Japan is pushing forward with passing laws to regulate open communications. It seems to be targeted at protecting young people from public online sites and mobile content but the nature of the law means that the regulations will extend to blogging and to online sites such as 2channel. This looks like something me and my fellow bloggers in Japan will need to follow closely.

So the last few days I've been playing around with MochiKit and working with Javascript. Until now I have done some Javascript here and there but not too much. MochiKit seems to make it a lot easier by providing you with lots of useful functions for things you do often. In fact it's so popular that I have a hard time explaining to myself why I hadn't tried to use it up until now. I'm certainly not on the bleeding edge here.

Anyway, like I said, MochiKit makes JavaScript less painful. I have a little mockup for a page that defers going to the server until the user has stopped entering data for 3 seconds. That cuts down on a lot of back and forth between the server and client. It's easy in MochiKit. Just use the callLater function.

In this example the callLater is used to call another function, deferredupdate, after 3 seconds. However, if the user enters data a second time before the three seconds are up then the deferred object will be cancelled and a new deferred object will be created. This has the effect of not calling the update function until a user is really done entering data.

The request object is created in the deferredupdate function.

The deferredupdate function calls loadJSONDoc which creates a deferred object as well however this deferred object doesn't wait for any time it simply does it's work in a separate thread and executes a callback when it's done. In this case I set the callback to be the pageupdate function. The pageupdate function does the work of putting the resulting data into a table and adding that table to the html DOM.

If you are wondering what the bind function does, it always ensures that the 'this' reference works. I'll leave the full explanation for another post.

Most people who program in JavaScript already know about MochiKit but if you are interested in it check out the screencast at http://www.mochikit.com/

I found out today that the principle author of a popular Javascript/AJAX library Mochikit is my former highschool classmate Bob Ippolito. I remember him being pretty smart. I supposed he would make a name for himself in some CS circles and it looks like he has. He is also apparently a co-founder of Mochi Media, a company that makes products for content creators. Mochibot can be used to track usage of Adobe Flash content. It looks like they are moving into some advertising space by creating an advertising system for casual online games.

Interesting that Bob has moved into this area. Mochikit looks like it's had some extensive work done on it in the past few years so it looks like it's matured well but I imagined a bit more technical, low level path like kernel or low level API development for Bob rather than the relatively high level application/library development in javascript/web applications. I guess everyone follows the buck in the end to some extent and the money is in web dev.

In the same vein as my first post bashing Internet Explorer I wanted to point out a few CSS bugs/unsupported features that are notable in Internet Explorer. For those who are not familiar, CSS is a stylesheet language which helps you to layout your forms. It's used on basically every major website on the internet. But Internet Explorer, even though it is the most widely used browser, does not support many of the features of CSS and when it does, sometimes the layout appears differently than in other browsers because Internet Explorer doesn't follow the rules for how the CSS should work. This post will cover those issues where Internet Explorer simply doesn't work at all.

PNG Transparency

The first issue affects this website and actually causes the CSS used by this site at the time of this writing to be non-standard (shh!! don't tell anyone! I'll fix it sooner or later). That issue is that Internet Explorer doesn't support PNG transparency. PNG files have in them a transparency level which allows translucent images. When you click on an image on this site like below it pops up an image and the background is darkened by another translucent png image. This doesn't normally work in Internet Explorer.

Normally you should be able to just set the background image like the following and the png will be displayed with it's inherent transparency.

#overlay{ background-image: url(overlay.png); }

But Internet Explorer displays it as completely opaque.

Instead, for Internet Explorer's sake you have to do some wierd hack that is Internet Explorer friendly.

Notice the wierd call to some Microsoft method for displaying images with alpha. This is totally non-standard and broken but necessary in Internet Explorer to display a png with transparency (there are other ways to achieve the desired effect in javascript however).

Button Hover

The second issue is that Internet Explorer doesn't support the button:hover attribute in CSS. Normally you can make a particular piece of a page such as a link or button behave differently if you add the "hover" attribute to it in CSS. This has been used a lot with normal links. Indeed this site uses a:hover to show different color links when you hover over them. Try it. The link goes nowhere but you can see that it changes when you hover over it. The same should be true for buttons. You should be able to change a buttons properties when the user hovers over it using only CSS.

button:hover {
  /*Your CSS here */
}

In fact you can use this hover effect with pretty much anything, such as table cells and rows. However IE only recognises the hover for links so it requires javascript. Check out this test page. Hovering over the button does nothing in IE. In order replicate this functionality in Internet Explorer you have to write some wierd javascript that sets the behavior of the button when the page is loaded. There are a number of ways to do this but the most straitforward is to use the whatever:hover script so you can make use of the hover attribute in css. It has some important limitations however so be sure to read the limitations section. Essentially the scripts adds a onMouseOver and onMouseOut events to the button which change it's stylesheet class.

Both of these problems have added difficulty to my life. The first stemming from this website and the second stemming from work. While web browsers have become a quite complicated piece of software, time spent fixing bugs because of broken implementations of standards is a huge waste of time. This is somewhat true for Safari and Firefox but especially true for Internet Explorer. No argument could counter that it is a steaming pile of dung and that you shouldn't use it. PLEASE STOP. The world will be a better place if you do.

Basically the title says it all. Since I started doing web development I've lost count of the number of bugs that I've found in Internet Explorer but I want to highlight a couple that were especially annoying to me.

1.) The <button> tag doesn't work. The button tag has a value attribute which is supposed to be sent as the value of the post when I submit a form but it's not. The display value of the button is sent instead. So if you have a form like so:

<button name='time' value='1030'>Click here</button>

and you submit the form that the button is contained in, the post value of time is set to "Click here" instead of "1030" like it's supposed to. Basically in IE you can't have a button submit a form and post a value different from the displayed value. This makes it very hard to have an array of buttons and post a different value based on what button you push.

2.) For e-mail links that contain Japanese characters you have to change the characters to the %0000; equivalent value. So if you have a mailto with a subject line in Japanese you can't write:

<a href='mailto:myperson@mymail.com?subject=おはようございます'>e-mail me</a>

and expect it to work. Internet Explorer simply does nothing. No error message. No e-mail client. You have to url encode the link to something look something like:

<a href='mailto:myperson@mymail.com?subject=%E3%81%8A%E3%81%AF%E3%82%88%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%26'>e-mail me</a>

which if you are using php is not so bad since you just call urlencode() but it's just plain annoying to get stuff like this to work when there isn't really a good reason why you need to encode it (at least I haven't heard one so far).

That's just the 2 most annoying bugs/issues. I can't imagine how the button bug got though the testing phase for IE but probably there are too many applications that depend on the bug working as is for Microsoft to ever change it to work the way it's supposed to.

I realize I shouldn't hold my breath, but the sooner everyone stops using IE the better.

This week I've been working on setting up several web service for a project I'm working on for work. Because we are creating these web services from scratch we had to start by creating a WSDL file to describe the web service and it's functions.

WSDL is a type of xml document that describes the inputs and outputs from a web service. This can be done using a number of ways but in my case I'm using SOAP so I described my inputs and outputs using XML Schema.

In learning about WSDL I found a number of documents helpful. Forthought Inc.'s Uche Ogbuji always seems to write good articles and Using WSDL in SOAP applications no exception. Also, examining existing documents that are publicly available was also a big help. Such as this example Stock Quote web service. Or the Google SOAP web service definition.

Though after reading all of those, while returning base types like int or string or even custom objects was easy to define, I had a hard time figuring out how to define how to return arrays of objects (Actually, Google's WSDL shows an example of what I'm about to describe).

I originally thought that returning a list of objects would simply involve returning more than one of the object. Like if I defined this in my types section:

for reference this is my message definition:

That's a perfectly fine piece of XML Schema but unfortunately web services clients and servers won't recognize it. Instead you need to put a restriction on your returned type to define the array you are returning as a http://schemas.xmlsoap.org/soap/encoding/:Array. Sounds hard but it is really just a matter of following the pattern below instead of what I did above.

The message definition doesn't need to change from above. After doing that your favorite web services client or server that supports WSDL should recognise that what you are returning is an array type properly.