Domain: simonwillison.net
Stories and comments across the archive that link to simonwillison.net.
Comments · 10
-
Re:Bug?
As Phil Karlton once said
There are only two hard things in Computer Science: cache invalidation and naming things
-
Re:That's simply not an adequate response
That statement has been pretty widely discredited by now.
(note: first link includes NSFW illustration) -
Re:The Fucking Crybabies
Per the article, which I know no one reads, the guy that made the remarks has a blog at http://simonwillison.net/
He may not have been there, but his point is that for an industry that's always trying to attract women, this is the wrong thing to do. Not to mention that even if it is culturally accepted in Taiwan, some developers may be morally opposed to this.
So we shouldn't be surprised when women don't want to enter the IT and Computer Science fields because they see it as a male dominated field. Images like these reinforce that perception. If you want more women in the field, do things that attract them. Don't trot out booth babes like it's an anime/gaming convention or a car show.
-
Orthogonal awesomeness
Apparently this site runs Django, and was built in but a few days. Great show of open source power there! Worth a mention IMHO.
-
Re:A simple request
Great! I like pork chops! What does that have to do with the subject at hand?
Worse. One of the whole points of jQuery is that it (a) makes it practical/easy to do js in this "right way" (b) furthermore, makes it difficult to do it any other way!
You build something that works fine without any js, for example links that go to <a href="page.php?id=4" class="tablink">, and then $(document).ready() gives you a functional place to remove those links and attach your
$('.tablink).click(function(){
// put in your funky ajax/dhtml way of showing the stuff in the id specified in this.attr(href) instead
})When using jQuery, you don't hardcode the ajaxy way into your <a onclick="javascript:"> attrib, because the $ object isn't guaranteed to be available. So, it pretty much forces you to do it properly and register an event the nice way - after the fact, separate to your well-formed structural markup. Oh, and you're selecting stuff with CSS selectors, so you're pretty much forced to do "right way" CSS too.
Before frameworks - you were in a world of hurt even figuring out how to attach events in a plays-nicely way (example). Even a fundamental like getElementByID meant browser incompatibility issues. You spent so much time tearing your hair out about this crap, by the time you had the javascriptified version working, you honestly struggled to care about the 2% of people surfing with js disabled.
By (a) taking away all this bullshit and (b) encouraging (through their documentation/community), if not outright requiring, a "best practice" type of "house style" / coding conventions, frameworks like jQuery actually let developers spend time writing useful stuff that you KNOW won't fuck people's shit up, because someone cleverer than you made sure it won't, instead of spending all your time writing boilerplate nonsense to make sure it doesn't fuck people's shit up.
I mean, seriously, where is the jquery plugin for loading a "billion popups"? Where is the John Resig blog post that advises you javascript means you don't need to check POSTs server side anymore? Oh yeah, they don't exist. So this is pretty much the last audience that needed that lecture (correct as it was, in it's own right). Still, I suppose it's too much to expect for there to ever be a js related story on slashdot without someone charging in with an irrelevant anti-js rant. Same as every phone story has to have the obligatory I JUST WANT A SIMPLE PHONE wahmbulance post. *sigh*
-
Re:Very Different from EC2
Sort of. Apparently, you can stay pretty close to Django:
http://simonwillison.net/2008/Apr/8/forms/
I would imagine that someone will also write some code to sit between your app and database, pretending to be the data backend that Google is providing, simplifying migration away from teh Goog. -
Re:Hmmm
I like the getElementsByCSSSelector() idea.
I think it's kind of self-defeating. On one hand he advocates custom-tag creation, then he advocates elements by tag selector. Encouraging one or the other is fine. But offering both will only confuse developers and undermine both options. Going with custom tags is probably the better solution as it encapsulates the semantic information a programmer would be looking for while still being unique enough to style with CSS.
That being said, if you really want that feature try this script:
http://simonwillison.net/2003/Mar/25/getElementsBySelector/I want javascript access to the css parse tree just like with the DOM.
I think you want to read the DOM Level 2 Style Specification. The short answer is: Yes, the CSS is accessible through DOM APIs. The long answer involves lots of shouting and complaining about Microsoft and their stranglehold on the market. :-) -
Re:How long
It's a pity that OpenID somehow doesn't take off as many expected and I don't think a Microsoft solution will either. Google comes to mind as one company that could probably do it successfully.
There are plenty of OpenID providers at this point; it's just a matter of getting more OpenID consumers now. Firefox is planning on adding native OpenID support real soon now, and I wouldn't be the least bit surprised if Google picks up on it as well. Yahoo is promoting their own account instead, although you can use your Yahoo! ID as an OpenID identity via idproxy.net.
Of course, none of this means that OpenID is guaranteed to become the ubiquitous identity standard, but it's not exactly dead in the water either.
-
Re:Okay, I'll be the first to ask.
This is no news and your next best AJAX implementation is only affected if they deliberately allow cross-domain calls.
As far as I understand this article - and it's very short on details - this only affects AJAX APIs / apps that are designed to be called from other domains.
Usually, an AJAX reply just contains data (XML, JSON, or in another format). But if the reply is actually valid JS, e.g. a callback function, you can include it via the script tag and call the returned callback function to read the cross-domain JS reply in JS and do something with it.
See here or here.
Bottom line: Don't expose any data / functionality through an API that allows cross-domain XHR unless you add additional precautions. -
Re:Jimbo...who are the founders?
I would say it is more of a difficulty of running a large, open and inclusive system than it is a fundamental problem(mostly, this implies it can be fixed). At the moment, the more 'invested' party in a dispute can often win, simply by spending more time on it. Some sort of reputation system would mitigate this, but it probably has problems of it's own(how do you build credit when you don't have any, etc). There is some stuff like this taking shape around OpenID, e.g.:
http://simonwillison.net/2007/Jan/22/whitelisting/
Take something like that(basically, white listing slightly trusted OpenId commenters), throw in a reputation broker or two(that aggregate opinions and opinions of opinions and so forth), and you might actually end up with something worthwhile.
I'm not sure it would work, but it seems like it would be sort of nice to be able to carry a 'positive contributor' label around, and that plenty of sites would welcome the additional information about their users.