From the Microsoft security center:

So when we release the next cumulative IE security update, customers will only be able to interact with Microsoft ActiveX controls loaded in certain web pages after manually activating their user interfaces by clicking on it or using the TAB key and ENTER key.

I'm assuming that this applies to visible ActiveX controls only, and that scripted ones are still OK. IE is going to be in a very sorry state otherwise.

Since this is all about the Eolas case which was all about visual components I guess this is a safe assumption.

Also from the same announcement:

The good news here is that we are on a path to include the fix for the zero day vulnerability as part of the April IE cumulative security update and possibly sooner if our ongoing monitoring and analysis of attempts to exploit vulnerability shows customers are being impacted seriously.

I'm not sure that it's good news that we have to wait a few weeks for a fix to a fairly serious IE hole that is currently being exploited, but at least there is a fix on the way.

Responses[1]

Posted by Joe Walker on 30 March 2006 08:38:52 BST #

JSON-RPC:

There are 'quite a few' Ajax frameworks in nearly the same way that there are 'quite a few' stars in the sky, however not many that do the same sort of thing as DWR. From what I've seen the biggest competitor DWR has is JSON-RPC, which has just released 1.0, so congratulations. See also the changelog and the downloads.

RAP:

Mike Milinkovich mailed me the other day with a heads-up on RAP (Rich AJAX Platform), which seams to be a port of the Eclipse RCP platform to Ajax.

"The RAP project aims to enable developers to build rich, AJAX-enabled Web applications by using the Eclipse development model, plug-ins and a Java-only API."

There is a demo of it in action here.

Responses[1]

Posted by Joe Walker on 28 March 2006 10:07:51 BST #

I've seen quite a few ideas and bits of policy writing about accessiblity that could probably do with some updating. These are the 3 most common.

Myth 1. Accessibility is a single issue

One of the problems with accessibility as a single concept is that it lumps together issues that are sometimes fairly unrelated. Blind people have different accessibility requirements from partially sighted people, or those with motor impairment. People with slow modems need different things from those on corporate networks with strict security. We need to think about separate requirements, ... separately.

Myth 2. All accessibility issues must be fixed

Our attitudes to these disabilities should also vary between accessibility issues. We can't ignore blind people from a moral or legal standpoint. Do we ignore someone that really likes his or her copy of Netscape 3 and doesn't want to upgrade? Now it's a business decision, not a moral or legal one. There are many issues like text-mode browsers and small screens that accessibility books handle. We don't always need to address them all.

Myth 3. Javascript won't work with screen readers

Screen readers mostly work by plugging into IE or Firefox and reading what's on the screen. It doesn't matter how it got there. More advanced ones actually let you fire off onmouseover and onclick events using the keyboard and will inform the listener that there is an action worth considering. That's more feedback than sighted users get sometimes. Screen readers do have a problem with content that's generated at a point on the screen that has already been read. This is where Ajax may have the biggest issue with accessibilty, and something that we need to be aware of.

It's great to have got DWR 1.1 out of the door (check the detailed release notes and download it). One of my focuses for DWR 2.0 is making it easy to create websites that interact with screen readers to solve the problem of generated content.

Responses[6]

Posted by Joe Walker on 09 March 2006 18:38:03 GMT #

We're interviewing for Architects at work. There are stacks of sample tests around the web for programmer level roles, but not a lot for architect level roles. So we devised our own.

We tell the applicants that these questions should be answered in bullet list / note form. We don't need essays because we are going to talk about some of the issues in the interview.

• What in your opinion is the worst part of Java development? How would you fix it?
• What advice would you give a server side web developer wanting to ensure that new code was secure from external attacks?
• Do you think Component based frameworks are better than Action/Request based web frameworks?
• What recent technology trends are important to enterprise web development?
• What do you think of Struts?
• What's the difference between final, finally and finalize?
• Rank the following attributes in order of importance when designing new code. If you have time, please add a sentence to each explaining it's position:
• performance
• maintainability
• correctness
• ease of use
• ease of learning
• Some performance tweaks serve only to make source code hard to read, without really making a significant difference, others are vital to a system returning results in a finite time. When in the development process should you consider performance issues?
• A customer has asked you to write a toUpper function. The only requirement you have is:
  • It must return 'A' when given an input of 'a'.
  What questions do you need to ask to flesh out the requirements?

These are not trick questions - there is generally no one correct answer; just opinions. (Except question 4 of course; You get hired instantly for mentioning DWR ;-)

Is this a good way to sorting the men out from the boys?

Send me your CV If you are interested in an architect role in the East Midlands, UK: <joe at getahead dot ltd dot uk>

Responses[21]

Posted by Joe Walker on 01 March 2006 13:22:25 GMT #