From Nikhil, an autocomplete textbox implementation for Silverlight. It helps demonstrate a “behavior” system he posted a few days ago. I wrote a very similar behavior system in WPF a while back, so I’m glad to see that a very similar pattern can be done in Silverlight. It makes extending and enhancing controls simpler, easier (and even more powerful as you can combine behaviors, whereas inheritance can be tricky if you want to apply multiple unique functions to a single UI element).
Category / Coding
Technical Interview Question #4
Write a function that determines if one file path is entirely contained within another file path. You can ignore escaping such as %20, but you cannot ignore directory change sequences such as “..” for “up one level.”
What’s the perfect API?
I was skimming a rant by someone on arstechnica about how badly messed up Win32 APIs are and how superior everything else is, when this paragraph grabbed my attention:
The reason must be that no one in Microsoft actually gives a damn. Each group develops their own UI widgets in their own style and they simply don’t care that it’s a total mess. They don’t care that I have to learn new ways of doing the same task just because they couldn’t be bothered to do things the same way as other applications. I’m not saying, for example, that they shouldn’t have introduced the ribbon concept in Office 2007, because it seems to work pretty well, and I can believe that it really is a better UI model. But they should have taken stock of what they were doing and made it a system-wide UI device. New widgets and UI models do crop up from time to time, but they should be rare, and when they do appear, Microsoft should make them general so that everyone can use them.
The article/post contained a lot of conjecture and fact-less information up to that point, and had strayed into the Vista-bashing camp that so many love when that paragraph smacked me. It’s where I went from having very little respect for the author to near zero. I mean seriously — how could you honestly write that no one cares at Microsoft? Not a single person? Right. There are some misguided teams and products at Microsoft from time to time (and some great products that are canceled), and maybe some products that he or I don’t agree with, but come on — there’s plenty of people who want to produce a product that others will use and enjoy (or at least find useful)! Does the author of that article honestly think, Microsoft employees get up in the morning, and think to themselves, I couldn’t care less about my future or any of my customers — I’ll go do the least amount of work I can to get my job done — and produce something barely adequate.
I frequently see someone posting, “I’m joining Microsoft … so that I can not make a difference and not care!”
A few other zingers from the post…
If you develop software for a living, and were to say something to me in an interview like this:
Another example; Win32 has a function for getting the size of a file. File sizes on Windows are limited to 2^64 bytes, and so they need a 64-bit integer to be expressed easily. But the API call to get the size of a file doesn’t give you a 64-bit value. Instead, it gives you a pair of 32-bit values that have to be combined in a particular way. For 32-bit Windows, that’s sort of understandable; 32-bit Windows is, well, 32-bit, so you might not expect to be able to use 64-bit integers. But if you use the same API in 64-bit Windows, it still gives you the pair of numbers, rather than just a nice simple 64-bit number. While this made some kind of sense on 32-bit Windows, it makes no sense at all on 64-bit Windows, since 64-bit Windows can, by definition, use 64-bit numbers.
It shows such an immaturity of what it takes to do long term programming (not just one-off programming for hobbies) and API maintenance that you’d be a “no-hire.” Dude, do you seriously want to conditionalize all of your code just so you can recompile on 64 bit Windows? Do you want a new API just for that? Seriously, what’s the gain?
So clearly, …
So Windows is just a disaster to write programs for. It’s miserable. It’s quite nice if you want to use the same techniques you learned 15 years ago and not bother to change how you do, well, anything, but for anyone else it’s all pain. I thought before that Microsoft cared about people like me. But it doesn’t. And it makes programming on Windows painful. Microsoft is great at backwards compatibility—you can take really old programs and compile and run them on a brand new Windows—but terrible at design and terrible at providing a good experience.
He applauds OSX at some point — coming to the conclusion that the Mac OSX APIs are genius … never mind the fact that Apple had to start over from scratch and every application needed to be rewritten (and the fact that the whole thing was inspired by the NeXT OpenStep). Maybe they are wonderful — I’ve only dabbled (but seriously, Objective C??!?). Microsoft could have done that too — but when you have the market share Microsoft has — can you truly afford to do that? No way. Hundreds of millions of people every day use legacy software on modern Windows operating systems because Microsoft made the difficult choice to keep supporting them.
As the author goes on to say, it causes the internals of Windows to be less than completely desirable as it is forced to maintain a level of compatibility with old APIs and peculiarities of older versions of Windows. Are there people working at Microsoft right now who would love to just start fresh with a clean slate? Abso-freakin-lutely. But, business needs often come first in the world of making money. Microsoft was able to keep existing products running because of the design of their OS and APIs made it possible. Apple couldn’t with OS 9 and earlier when upgrading. When they can completely virtualize a Win32 process seamlessly — then they can start fresh.
Taken alone, these are all fairly minor things. Put together, the interface is just completely shambolic. It looks amateurish. The quirks of each new interface have to be learned anew. This slap-dash approach to look-and-feel gives the impression of a platform that no one really cares about.
The author seems to believe that everyone at Microsoft should just work together and produce products at the same time on the same ship schedules — as every one should contribute the “whole” and produce things that are only good for the masses. They aren’t allowed to innovate on their own or produce something unique or better than another team. “Just stick the widget into the OS … we’ll ship when you’re ready … and we’ll happily adapt to any changes that any other team needs to make.”
If the author had chosen to research and provide facts, better understand the development environments, platform capabilities, and stick to a point, it might have been a mildly interesting read — but alas, he did not. It got my blood boiling …, hence my post. Maybe Microsoft, who couldn’t care less according the author, will nonetheless contact him to get feedback on how to build the perfect API. Clearly it can’t ever have a backwards-compatibility layer or object model … so it just has to be perfect right out the door. :-P
What is the perfect API? For rich or a reach application? Give it a little thought right now. What comes to your mind right away?
Top 10 web security vulnerabilities
Check out the top 10 for 2007 security vulnerabilities for web applications presentation here (available as a PowerPoint presentation).
The top 10 is:
- Cross site scripting (XSS)
- Injection flaws
- Insecure remote file include
- Insecure direct object reference
- Cross site request forgery (CSRF)
- Information leakage and improper error handling
- Broken authentication and session management
- Insecure cryptographic storage
- Insecure communications
- Failure to restrict URL Access
If you’re a web developer, do you know what each of these mean and whether your code is vulnerable? If not, you need to know.
Silverlight — it ain’t your papa’s WPF
John Gossman, architect of the WPF team (desktop and subset taht supplies UI framework for Silverlight), discusses a few of the pain points developers and designers are facing today with WPF to Silverlight portability. From his post:
The above example is a bit of a special case, and I don’t feel bad about it at all. A much greater struggle that hits a very large number of users is how we do Control templating. All of the APIs we use in Silverlight’s Beta1 control templating model exist in desktop WPF, and yet the templates are completely different. By subsetting the APIs we ended up changing not just the best practices, but the essential model.
Let me be clear. If you write your own custom control in Silverlight, using the Silverlight model, you can create a template for it and take your custom control and its template and run them on desktop WPF. The problem is, we do not provide Triggers in Silverlight and many of the properties (IsMouseOver, IsPressed) that Triggers depend on to work. There are technical reasons Triggers were hard to add in Silverlight 2 (though we will add them in the future), but even greater was the test and development cost of adding all the additional properties necessary to make them work. So, we decided to make the controls have to “trigger” the state changes themselves in code. All this code works on desktop WPF. But existing controls, written for the desktop, don’t contain the code to “trigger” the state changes, so the control templates don’t do anything when applied (they create their children, but don’t react to events).
The more I consider this … the less I care about portability specifically between WPF and Silverlight. It’s unlikely that I’ll ever be able to use or need to use code exactly as it was written for a desktop WPF application (yes, there will be elements that are worth copying — but I believe that a full installed application should work differently from an enhanced web page with Silverlight). If I’m running a WPF app — I’m running a thick, rich, installed application (or click-once). If I’m writing something for Silverlight, I need to write code which lives within the confines of the browser. Although similar, they’re still quite different on many levels.
That being said, I would like the models to be the same — if only because I’ve really become fond of many of the WPF features and techniques for building a user interface: triggers, triggers, and triggers. I can absolutely live without 3D and even without a full .NET framework. But triggers really help separate the UI from the code. I’ve done some investigation and I can’t see how I could create a reasonable approximation of Triggers without a lot of work — and even then it wouldn’t be compatible with WPF XAML. John said “when we add triggers…” …, so it gives me a bit of hope (albeit with no time tables…).