A haboob hit Phoenix last night. This morning the streets were ridden with dust, the pool was brown with an inch of dirt on the bottom and everything caked in a layer of light brown. The damage on our house was a shade sail ripped down and an Octillo pulled out of the ground. A haboob is described as:

During thunderstorm formation, winds move in a direction opposite to the storm's travel, and they will move from all directions into the thunderstorm. When the storm collapses and begins to release precipitation, wind directions reverse, gusting outward from the storm and generally gusting the strongest in the direction of the storm's travel.

When this downdraft, or "downburst", reaches the ground, dry, loose sand from the desert settings is essentially blown up, creating a wall of sediment preceding the storm cloud. This wall of sand can be up to 100 km (60 miles) wide and several kilometers in elevation. At their strongest, haboob winds can travel at 35-50 km/h (20-30 mph), and they may approach with little to no warning.

Apparently the winds last night were about 60 mph but the news at the gym could be exaggerating. Television news tends to do that making it untrustworthy. Either way the dust storm hit the house with a loud thud and then teared up anything in its way. The house has a fine layer of dust on the floors and counters as well. It will probably take a week to clean the dust and dirt up.

More Another time lapse shot of the haboob developing.

I am installing Oracle's database on our iMac. To get it to install I need make, which is in XCode. I know that XCode comes on the install dvd, I also know I can download by using a developer login I have with Apple - there is also the app store where is $4.99 which for convenience won out.

Kind of amusing I just paid $5 for make, which is free and opensource, I also paid $5 for a multi gigabyte download of XCode when make is probably all of 9kb as a binary. Such is the price of convenience when we have ample bandwidth and money.

It looks like the traffic camera programs the towns and cities in Arizona are running are generally not creating any revenue for them. The companies running the programs - including Redflex and Australian company - are making money, and so is the state due to a surcharge on the issuing of tickets, but the cities and towns which the majority of the processing work falls on are not.

I think the traffic cameras are a bad idea and do not solve any of the problems that are put forward to justify them. Worse the cause traffic to flow in arbitrary ways as people throw out the anchors when they see them even if they are under the speed limit. Thankfully they have been removed from the state highways, but the mobile ones and the mounted cameras are still used by the cities and towns.

Scottsdale doesn't seem to know how much the processing costs and can't say if they are making money, neutral or losing money. Good on the Arizona Republic for requiring this level of accountability and asking for the information;

Scottsdale, Tucson, and Surprise could provide only rough estimates for expenses for city court staff to process the tickets and conduct hearings for people challenging citations.

Without an analysis of the revenue and expenses, it is difficult to determine if they generate profits or losses, although the data and estimates from the cities point to losses. ...

Of the three cities that don't regularly track their programs' costs, Scottsdale has the highest revenue, and officials there estimate that if they did track staff costs, those costs would eat up the $427,000 in revenue left after paying the camera company and the state, making it just a break-even program for the city.

The amount of money the state makes from the surcharge on the traffic tickets from seven million which is about the same that Redflex and ATS made from supplying the vans and services for traffic cameras. Not sure why the towns continue with the program if these numbers are correct. Seems like a bad deal for no gain considering there are plenty of studies which show that traffic cameras do not improve public safety.

Update: Tempe is getting rid of the photo cameras;

At its July 7 meeting, the City Council's Formal Meeting agenda included an item to extend the Redflex contract for three months. Mayor Hugh Hallman proposed the Council instead consider extending the contract for one month. Councilmembers voted 4 to 3 to reject that motion, effectively ending photo enforcement in Tempe as of the existing contract's July 18 expiration date. Cameras would be turned off at midnight July 19.

Which is a good decision IMO.

Interesting article on the vagaries of copyright enforcement and what constitutes fair use. Pixel art is the point of contention. Like most things to do with the legal system, getting sued is expensive and it is often cheaper, easier and less stressful to settle.

Copyright is an artificial monopoly created by government. Arguably is was created for the purpose of public policy and public good. One of the problems with government creating monopolies is that the benefit becomes entrenched and those who are benefiting from the monopoly do not want to give it up and lobby for the monopoly to remain.

There are numerous studies showing that innovation is faster when there is no copyright or patent protection. Johanna Blakley has a talk showing how the fashion industry innovates and remains economically viable despite not having patent or copyright protection.

One of my favourite stories as a young child was Henry Lawson's the loaded dog. The gangly dog running around with explosives in his mouth was too funny. It even had a small moral lesson at the end when it all ended well. This video of a puppy grabbing a rocket reminded me of the loaded dog, the people running around in fear because the dog has the rocket in his mouth is too funny.

Horrible day; trying to merge a feature branch that had been out of main for too long and that had a lot of build changes and cleanup in it. Tree conflicts galore and subversion is one of the weaker source version control mechanisms when it comes to merging. Perforce would have done this standing on its head.

Between the command line, cornerstone and subclipse/eclipse, along with the steady hand of a co-worker most of the merge is complete, but what a nightmare. It was replete with two false starts, one auto-destruction of the working copy courtesy of a misplaced click on resolve in cornerstone.

Time to relax in the pool with a beer in the 110F Phoenix heat.

Javadocing tends not to be done and it is often a case of fighting against the tide in trying to get people to do it, but it is important. It describes why decisions that seems obvious at the time, can be explained and understood five years in the future when the same code needs to be modified.

We have a complex data structure that is hard enough o understand on its own without the additional complexities that JPA places on top when you specify those relationships in entity beans and using annotations. This for instance makes sense, and the cascade type of merge also makes sense in this case, it lets me know how to modify it.

@OneToMany(mappedBy="someDubiousRelationship",cascade={CascadeType.PERSIST, CascadeType.MERGE})
	private List

However in the same complex structure the underneath way of achieving the same end has this:

@OneToMany(mappedBy="priorEntity")//, cascade={CascadeType.PERSIST, CascadeType.MERGE})
	private List

It has a commented out cascade type. Oh oh, why? Why was this decision made? And why can I merge one side of it and not the other? Since these entities run in a kind of circle it is important to document why they are like this and why these decisions are made. It is not obvious.

I think javadocs are a courtesy to other developers you are working with so they know why things are being done the way they are done. When you are working with the code there and then it is blindingly obvious why things are being coded the way they are. Another person coming in 24 hours later does not know. Worse, if you go back to the same code a year later, you don't remember or know either. Often javadocing is a courtesy to yourself.

I know people don't do it, but I don't consider that a good enough excuse. I javadoc and javadoc heavily. I think it is good manners if nothing else. Besides, javadocs are valuable too. Once code is locked down with unit tests it rarely changes without some element of refactoring, unit tests kind of dictate that approach.

One of the problems with online privacy is that you don't really know what is being leaked out as public data. You expect that most stuff is private, but the terms and conditions can change quickly - which facebook has a bad history of - or worse, something you assume would be private is actually public and it is non-obvious.

The Amazon Wishlist is in the latter category. You can view anyone's wishlist if you know their email address. Which I don't think is cool. I changed it to private but I was unaware that this was public information. My wishlist is boring, no dildos or anything like that, it was just books on software and classical history, but even so.

Part of the normal ebb and flow of my inbox is emails from recruiters. I received one today that had as a requirement for a position;

Ability to write 'social' code

I am pretty good at writing code that gets along with other classes, methods and forms of abstraction. Social code is the new must have ten years of java experience and 'we need more URL'.

I was looking for a best practices for login forms and sign up dialogs when I came across this interesting summary of how websites are handling this function. Some of the interesting trends were that:

93% are one page sign up forms
86% are vertically aligned rather than horizontal

I am sure most of these practices are emergent from ruthless A/B testing. It is interesting to see from an empirical point of view as to what the major websites are doing as opposed to Usability testing.