Quotations
Filters: Sorted by date
The Google App Engine model class, db.Model, is not the same as the model class used by Django. As a result, you cannot directly use the Django forms framework with Google App Engine. However, Google App Engine includes a module, db.djangoforms, which casts between the datastore models used with Google App Engine and the Django models specification. In most cases, you can use db.djangoforms.ModelForm in the same manner as the Django framework.
Ignoring reality in favour of what we would like to be true doesn't actually work. This simple axiom probably underlies almost everything the WHATWG has done so far, and it has so far served us well.
The ISO are now calling a "standard" the Microsoft Office format [...] What is interesting is that TeX, LaTeX, OGG/Vorbis, OGG/Theora, Perl, Python, PHP, Ruby, OCaml, are not standardized by any organization. [...] This shows that standardization organizations are no longer relevant in the software field. What really matters is free full documentation, free full implementation source code, and of course the absence of any patent risk. [...] In other words, what matters is evidence that any independent third-party can create and distribute a fully-conforming implementation.
NOTE TO INTERNATIONAL DEVELOPERS: PLEASE DO NOT MAKE SERIOUS ANNOUNCEMENTS ON INTERNET JACKASS DAY.
Ian's Acid 3, unlike its predecessors, is not about establishing a baseline of useful web capabilities. It's quite explicitly about making browser developers jump - Ian specifically sought out tests that were broken in WebKit, Opera, and Gecko, perhaps out of a twisted attempt at fairness. But the Acid tests shouldn't be fair to browsers, they should be fair to the web; they should be based on how good the web will be as a platform if all browsers conform, not about how far any given browser has to stretch to get there.
The Perl community has a long-standing love/hate-affair with making changes that impose "spooky action at a distance". They call it "black magic" and it is generally considered it a last resort. Black Magic that makes GLOBAL changes to things like inheritance is often characterised as being "Octarine" (see disk world novels), because it tends to work ok when there's only one person doing it, but start to mix a few together and KABOOM!
Draconian failure on error is not the answer problems of Postel's law. Draconian error handling creates an unstable equilibrium in Game Theory terms - it only lasts until one player breaks the rule. One non-Draconian XML5 implementation in key client product and the Draconian XML ranks would break. Well-specified error recovery is the right way to implement the liberal part of Postel's law.
For the record, my site is valid HTML 5, except the parts that aren't. My therapist says I shouldn't rely so much on external validation.
We've decided that IE8 will, by default, interpret web content in the most standards compliant way it can. This decision is a change from what we've posted previously.
— IEBlog
"Why doesn't jQuery have an XPath CSS Selector implementation?" For now, my answer is: I don't want two selector implementations - it makes the code base significantly harder to maintain, increases the number of possible cross-browser bugs, and drastically increases the filesize of the resulting download.
Let me be again clear here that Comet isn’t a new single technique. Rather, it’s a combination of existing push technologies with further research into new methods that together provides a robust framework for pushing data to all clients on modern networks.
Since 9/11, approximately three things have potentially improved airline security: reinforcing the cockpit doors, passengers realizing they have to fight back and - possibly - sky marshals. Everything else - all the security measures that affect privacy - is just security theater and a waste of effort.
In a recent [ASP.NET] MVC design meeting someone said something like "we'll need a Repeater control" and a powerful and very technical boss-type said: "We've got a repeater control, it's called a foreach loop."
If Web authors actually use this feature, and if IE doesn't keep losing market share, then eventually this will cause serious problems for IE's competitors — instead of just having to contend with reverse-engineering IE's quirks mode and making the specs compatible with IE's standards mode, the other browser vendors are going to have to reverse engineer every major IE browser version, and end up implementing these same bug modes themselves.
No matter what great leaps forward the Internet Explorer team make from now on, the majority of developers won’t use them and the majority of users won’t see them. By doing this the Internet Explorer team may have created their own backwater, shot themselves in the foot and left themselves for dead.
If you want CSS rules to apply to unknown elements in IE, you just have to do document.createElement(elementName). This somehow lets the CSS engine know that elements with that name exist.
Like DOCTYPE switching did in 2000, version targeting negates the vendor argument that existing behaviors can't be changed for fear of breaking web sites. If IE8 botches its implementation of some CSS property or DOM method, the mistake can be fixed in IE9 without breaking sites developed in the IE8 era. This actually makes browser vendors more susceptible to pressure to fix their bugs, and less fearful of doing so.
The thing that disrupts you is always uglier and worse in some way. Less features, less developed. But if there's a 10X price win in there somewhere, the cheap rickety thing wins in the end.
Yahoo!'s provider implementation only supports consumers that talk the Auth 2.0 protocol. Technically the 2.0 spec allows providers to shun 1.1, but it's not recommended for the reason that I'm sure will become obvious once Yahoo! launches: there's no way for your average end-user to distinguish between a 1.1 and a 2.0 implementation.
Oh, and before anyone jumps on me about this not being "full" (meaning bi-directional) OpenID support, I'm quite aware of that. Consuming OpenID is a different beast that can't happen overnight. Give it some time. I'm optimistic that we'll get there.
A Yahoo! ID is one of the most recognizable and useful accounts to have on the Internet and with our support of OpenID, it will become even more powerful. Supporting OpenID gives our users the freedom to leverage their Yahoo! ID both on and off the Yahoo! network, reducing the number of usernames and passwords they need to remember and offering a single, trusted partner for managing their online identity.
I've never heard anyone from the REST camp claim that building distributed systems was "easy". [...] The WS-* folks have historically been obsessed with making things easy, usually for an imaginary business analyst who is nowhere near as technically adept as they. The REST folks, on the other hand, seem much more interested in keeping the entire stack simple, and for everyone involved.
Schools and colleges should make pupils, teachers and parents aware of the range of free-to-use products (such as office productivity suites) that are available, and how to use them.
— Becta
In my opinion it is better to compare OpenIDs to credit cards. [...] Just as a credit card company may place limit on the level of guarantee, web sites are at liberty to restrict the OpenIDs it will recognize and accept. Just as many of us carry more than one credit card, we may have multiple OpenIDs and use them for different occasions. Just as some department store credit card is not accepted outside of that store, it is possible that IDs issued by some OpenID providers may not be accepted by some sites.
The Flickr [OpenID] implementation, coupled with their existing API, means we could all offer things like "log into my personal site for family (or friends)" and defer buddylist management to the well-designed Flickr site, assuming all your friends or family have Flickr accounts.
The data portability folks want to make it easy for you to jump from service to service. I want to make it easy for users of one service to talk to people on another service.
From my perspective, it is crucial for Linux to have good support for Silverlight because I do not want Linux on the desktop to become a second class citizen ever again. [...] The core of the debate is whether Microsoft will succeed in establishing Silverlight as a RIA platform or not. You believe that without Moonlight they would not have a chance of success, and I believe that they would have regardless of us.
For me, the big problem with Facebook is the plain fact that it's an extremely annoying piece of software. [...] The central issue for me is that Facebook suffers a severe reverse network effect: the more people who join, the less useful it becomes.
The strain due to the fact that most business desktops are locked into the Microsoft platform, at a time when both the Apple and GNU/Linux alternatives are qualitatively safer, better, and cheaper to operate, will start to become impossible to ignore.
— Tim Bray
The technological future of the Web is in micro and macro structure. The approach to the micro is akin to proteins and surface binding--or, to put it another way, phenotropics and pattern matching. Massively parallel agents need to be evolved to discover how to bind onto something that looks like a blog post; a crumb-trail; a right-hand nav; a top 10 list; a review; an event description; search boxes.