You missed the point of the grandparent. The point is that Spamhaus shouldn't require X-Orig or any other X-* header, as those are not required by standards. It is irrelevant whether headers are added or removed during transit.
And you miss the point of spam filtering. Nothing in the standards says it's OK to drop messages which contain the word 'c14lis', so does that mean it's a violation of standards to "require" messages not to include it? If spam heuristics indicate that the overwhelming majority of messages which meet certain conditions are spam (e.g., false positive rate less than a fraction of 1%), it makes sense to start dropping those messages. That one of those conditions is the presence or absence of a header has nothing to do with "standards", because SMTP is not being violated.
Cool - now non-standard headers (the X- prefixed ones) are all of a sudden required? Interesting interpretation of standards...
Know what? Messages that contain the phrase "ch34p c14lis" are probably going to get blocked, too, but nothing in RFC822 says to do that. You should lead a revolution or something.
What does Flock provide? It forces you to accept its chosen plugins. That's bogus. I don't want any browser to chose my photo sharing community or be forced into using their web2.0 partners.
Um. So... don't use it, then? Is someone from Flock standing next to you and holding a gun to your head?
And in the meantime, people who do use Flickr, del.icio.us, etc. may be happy to have something that offers tighter integration with those services. To each his own.
Well, del.icio.us, Flickr and blogging have all been going strong for longer than 12 months already, so... odds might not be so great that they'll just be "passing fads".
He later states that LAMP is like BASIC which encourages bad habits. This is hyperbole, but one that I'm not totally disagreeing with because I don't know enough to make a truly educated argument.
I do know enough to make a truly educated argument; MySQL isn't as bad, though it does, as the author of TFA points out, tend to give novices the idea that "this is all there is to SQL" when it's not by a long shot. PHP, on the other hand... register_globals (want to hack a PHP site? Try adding "?username=admin" to the end of a URL, and if register_globals is on you just might succeed), magic quotes (rather than teach programmers how to properly check input, let's try to do it for them in a way that fails half the time and gets in the way the other half!), safe mode (why teach real security when we can just implement a couple restrictions and pretend that makes us safe?)... a lot of cool things have been done with PHP, and it's a good language for an experienced programmer who needs to whip something up very quickly, but in comparison to other languages for letting you shoot yourself in the foot, PHP will load the gun, turn off the safety and help you aim.
Odd that he finds PHP and SQL bug-ridden, but Linux isn't.
He's not saying SQL in general is "bug-ridden"; he's very specifically criticizing MySQL and recommending people switch to SQLite or PostgreSQL depending on their needs.
Actually he's not saying that the tools themselves are "bug-ridden"; he's saying that PHP and MySQL encourage novices to learn the some bad practices.
Today's friendly fact check brought to you by the letter "K".
As can be seen in this reference, none of those great CSS2 properties are supported by IE. As much as I would love to use them, they simply do not work for the 50%+ of one's audience that uses IE.
Perhaps you could help me out here. I'm not a CSS expert by any means, but I currently have a requirement to implement a site that has three vertical columns, the leftmost and rightmost of which should be the smallest possible size to fit their variable content into and the central one should expand to fill the available space. I'd love to know how I can do this without a table, but I couldn't figure it out, and all the CSS layout tutorials I've been able to find will only do columns of predetermined width. Having wasted two hours on this fairly simple requirement now, I'm about to go back to using a table like I normally would.
And that is exactly why we need XHTML - such lazyness just plain won't work if you were using XHTML.
Well, it won't work if the document is served as application/xhtml+xml to a user-agent which understands that media type and uses an XML parser on it. But since "XHTML" to most people means "put a closing slash in the img tag and keep doing what I was doing before", I'm actually going to say yeah, it probably will work.
And perhaps because I can't resist a snarky comment, maybe their mailing list is more active because TG is harder to use, or maybe because they've got a lot of catching up to do;)
TurboGears appears to be under more active development than Django.
Out of curiosity, what did you use to come up with this statement? As someone who works at the company where Django was developed and thus follows development very closely, I'm frankly astonished by it; we just merged a gigantic development branch about a week ago, for example.
Uh guys? The two of these I saw as live examples did NOT work with IE7 Beta. I'm pretty sure we don't want to pick a winner that will immediately need to be replaced when MS releases their new browser.
One of them has a comment on the mockup saying he knows it's borked in IE and is working on it; personally, I don't mind seeing someone design to standards first and then fix for the "less capable" browsers. If only more people worked that way...
Wow, you almost had a point there. Nobody uses HTTP auth because it's so flawed and, regardless of the type of auth, uses a single token that, if it got out, could be used by attackers to gain access regardless of whether it's actually the password or not. I see that.
And then you cite a list of five different companies whose authentication schemes consist of... sending a password over the wire. Consider two situations, then:
I send my password to eBay's non-HTTP-auth login system, and use an encrypted connection to do so (thanks HTTPS!).
I send my password to an HTTP-auth login system at some other site, and use an encrypted connection to do so (thanks HTTPS!).
Do you really think that situation 1 is any more secure than situation 2?
And yes, no-one's used HTTP Authentication in years, which is why you linked to an atom-pub post where they're talking about how they're currently using HTTP Authentication.
I do not differ with the conclusion that sometimes resources need to be immediately accessible via a URL but some times they just don't.
If you're developing an application which transacts its business over HTTP, and you're not using URLs as the basic representations of your application's resources, you need to just stop now. You're hurting your clients, you're hurting the Internet, and you're hurting me.
Most of the applications I build have a user authentication system in the first place. You can't just access the system without first logging in so this is the first line in deflecting the user from immediately landing on said page.
Hi, I'd like you to meet my friends: HTTP 401 Authorization Required and HTTP 403 Forbidden. They're bult in to the protocol your app is using, so the libraries you're developing with had better support them, and they're extensible to use pretty much any authentication scheme you want to use. And then once somebody's authenticated into your system, you can -- gasp! -- let them fetch things using standard HTTP methods like GET!
I am not trying to shoehorn an archaic model onto a web model I am trying to develop new models which enable my developers to develop web applications quickly.
Actually, I think you're working with people who've never developed web applications before, and rather than have them learn the new platform they'll be developing on you want to make it behave just like what they're used to. Fair warning: it won't be long before doing business that way will put you out of business.
Imagine if I decided to move from web development into desktop apps, and the first thing I did was write a local HTTP server that my app talked to for all its storage and retrieval instead of using native filesystem functions. I'd look pretty damn silly, wouldn't I? Well, just imagine how damn silly you must look...
Not really. The idea behind Rails' scaffolding is to give you basic, unstyled example CRUD views that you're expected to throw away once you've built customized ones; they're a starting point. Django's admin application, on the other hand, is a production-ready, fully-styled application with manipulation of related objects, fancy JavaScript widgets (e.g., date and time selection, automatic population of URL "slugs", etc.), an auth system and full logging of user actions. And when I say "production-ready" I mean "production-ready": many Django applications in the wild find the stock admin application more than sufficient for their needs.
And the generic views really aren't scaffolding, either, because they're not meant to be thrown away and replaced with something you develop yourself, the idea being that some tasks (CRUD, lists of objects, detail of a particular object, date-based navigation, etc.) are so common you shouldn't have to write views to do them. So Django has a full set of generic views for these tasks, and all you have to do is route URLs to them for input and hook them up to page templates for output. I think the apparent similarity here comes from the nature of Rails' templates -- in Rails, the "view" and the "template" aren't separate, and you just have a "view" that's a mixture of HTML markup and embedded Ruby code. Django separates application logic from the templates, so a view in Django is pure Python, and returns a dictionary of variables and values to be used inside a template with deliberately simple syntax.
I haven't heard much about Ruby since the (geek) media blitz of over a year ago. How many people actually use Ruby on Rails? I see the same thing happening with AJAX.
It's bad for publicity, but a lot of development with the new generation of web frameworks is taking place behind corporate firewalls and under NDAs. Some frameworks do advertise lists of public websites which use them, though.:)
Re:Zope - What RoR wants to be when it grows up.
on
Ruby On Rails Goes 1.1
·
· Score: 4, Informative
In an educative and entertaining webcast, Sean Kelly, a Nasa/JPL software engineer, goes into the details of a project based comparsion between a set of web application frameworks and servers. Including the much hyped Ruby on Rails and Django. Various Java technologies, Ruby on Rails, Django, TurboGears and Zope are covered.
Except he got more than a few things wrong. To pick one example, he seems to be under the impression that Django doesn't support i18n/l10n when, in fact, we ship all the core Django applications with support for twenty-odd languages, and Django uses an extensible gettext-based system to make it easy to translate third-party apps and add new languages. We even include an i18n JavaScript library to make translation strings available to JS code. Our admin app even has a setting that chooses which language to render a page with based on the incoming Accept-Language header.
Moral of the story: nice video, but the guy hasn't necessarily done his homework.
What I missed in rails most is proper support -- and that includes decent scaffold generation support -- for what is the most frequent case in nearly every non-trivial database application: many-to-many relationships.
Many-to-many relationships? Rails may or may not have them (been a while since I last played with it), but Django most certainly does. We don't have "scaffolding" (though somebody's submitted a patch to do something similar), but we do give you a ready-to-go administrative interface built from introspecting your models, and it's got some nice tricks for displaying many-to-many relations. We also give you a lot of other useful stuff like generic views pre-written to handle most common tasks (CRUD, date-based object listing and navigation, etc.) so you just need to write templates and hook up to them; Django was extracted from the codebase of several large content-oriented sites, so it's really good at that sort of thing.
Disclaimer: I work for the company which originally developed Django. Though I didn't work there at the time; I applied because I liked Django and wanted more opportunities to work with it.
Echo2, is aimed at tackling the problem of a thin rich clients over the internet. It is not designed to supplant you standard page based web applications where bookmaking content is necessitated. For a portal type application it is not the right tool for the job. Where it is the right tool for the job is in building a dynamic application that is distributable and maintainable in a single instance.
Then why not take advantage of features of the Internet? If you're using HTTP, then every one of your content objects can be a resource accessible via HTTP GET at a unique URL, but too many "web application developers" fail to recognize that this gives them transparent, universally-usable storage and retrieval, programmatically accessible from pretty much every language on Earth, essentially for free. When you move into a new operating environment, you should adapt to that environment instead of trying to shoehorn another environment's worldview into it.
Why should a a JavaScript framework NEVER define methods on Object.prototype or Array.prototype? Code that requires a static definition of Array is clearly making incorrect assumptions about how the language is used, so I'd place the blame there, not with prototype.js.
I place the blame squarely on Prototype. Application developers should never have to worry that someone else has snuck in and modified the core language's behavior without their knowledge, because down that path lie nightmares of coupling and maintainability which are best avoided.
They still don't explain WHOSE idea the Ping attribute was, or offer a compelling reason for its inclusion, particularly as it is something you can already do with onclick, as I mentioned here
The "ping" attribute was proposed by Ian Hickson on 21 October of last year, as a quick search in the WHAT-WG mailing-list archive would have shown if you'd bothered.
In his posting, Ian explaings the reasoning behind the attribute. You can do it with onclick, but then again you could manually write out every page of a dynamic website instead of using a CMS to automate the process.
I can't believe that after Firefox actually implemented tabbed browsing *well*, people insist on ruining it in the name of "progress".
You're absolutely right, you know. Having a close button on every tab completely removes or negates absolutely every single benefit of tabbed browsing, without hope of recovery.
Or not. People seem to use Safari, Opera, Galeon, and other browsers that do this, so maybe it's not quite the "ruins tabbed browsing" problem you think it is...
I'm very much looking forward to a 1.0 release of Django, if only so more people will have it as a hosting option. My experience with it was much more pleasant than Rails.
You and me both.
And I think you know exactly what kind of guy I am after that library linking point =) - yes, I do get very frustrated when libraries have poor modularization, and linking them for a handful of functions adds 2+ MB to your app (hello wxwidgets/qt). I suppose rapid development is the name of the game these days, an old hack with wild ideas about good cpu/memory usage is out of style.
I think that in the case of web frameworks, the OS analogy is apt; most OS APIs provide a lot of functionality that a particular application will never use, but in order to be general-purpose enough to support all the applications that will run on the OS, all that functionality needs to be there. Or one could quote the old adage about MS Word, that 90% of the features are used by only 10% of the users, but it's a different 10% for each feature.
And, FWIW, Rails isn't nearly as bad as, say, some of the Java frameworks when it comes to cluttering up your symbol tables with tons of methods you probably won't use;)
Slashdot Mirror
Cool - now non-standard headers (the X- prefixed ones) are all of a sudden required? Interesting interpretation of standards... Know what? Messages that contain the phrase "ch34p c14lis" are probably going to get blocked, too, but nothing in RFC822 says to do that. You should lead a revolution or something.
Um. So... don't use it, then? Is someone from Flock standing next to you and holding a gun to your head?
And in the meantime, people who do use Flickr, del.icio.us, etc. may be happy to have something that offers tighter integration with those services. To each his own.
Well, del.icio.us, Flickr and blogging have all been going strong for longer than 12 months already, so... odds might not be so great that they'll just be "passing fads".
I do know enough to make a truly educated argument; MySQL isn't as bad, though it does, as the author of TFA points out, tend to give novices the idea that "this is all there is to SQL" when it's not by a long shot. PHP, on the other hand... register_globals (want to hack a PHP site? Try adding "?username=admin" to the end of a URL, and if register_globals is on you just might succeed), magic quotes (rather than teach programmers how to properly check input, let's try to do it for them in a way that fails half the time and gets in the way the other half!), safe mode (why teach real security when we can just implement a couple restrictions and pretend that makes us safe?)... a lot of cool things have been done with PHP, and it's a good language for an experienced programmer who needs to whip something up very quickly, but in comparison to other languages for letting you shoot yourself in the foot, PHP will load the gun, turn off the safety and help you aim.
Today's friendly fact check brought to you by the letter "K".
OK, so let me hold your hand a bit: what you want is a combination of the table-related display values for the browsers which support that, and display: inline-block for IE. For example, it's used in this technique for making floats act somewhat like they're in the normal flow.
You do know about display: table-cell, right?
Well, it won't work if the document is served as application/xhtml+xml to a user-agent which understands that media type and uses an XML parser on it. But since "XHTML" to most people means "put a closing slash in the img tag and keep doing what I was doing before", I'm actually going to say yeah, it probably will work.
And perhaps because I can't resist a snarky comment, maybe their mailing list is more active because TG is harder to use, or maybe because they've got a lot of catching up to do ;)
Out of curiosity, what did you use to come up with this statement? As someone who works at the company where Django was developed and thus follows development very closely, I'm frankly astonished by it; we just merged a gigantic development branch about a week ago, for example.
One of them has a comment on the mockup saying he knows it's borked in IE and is working on it; personally, I don't mind seeing someone design to standards first and then fix for the "less capable" browsers. If only more people worked that way...
I saw it and thought, "Wait... I thought I turned *off* the Crux theme in GNOME..."
Wow, you almost had a point there. Nobody uses HTTP auth because it's so flawed and, regardless of the type of auth, uses a single token that, if it got out, could be used by attackers to gain access regardless of whether it's actually the password or not. I see that.
And then you cite a list of five different companies whose authentication schemes consist of... sending a password over the wire. Consider two situations, then:
Do you really think that situation 1 is any more secure than situation 2?
And yes, no-one's used HTTP Authentication in years, which is why you linked to an atom-pub post where they're talking about how they're currently using HTTP Authentication.
If you're developing an application which transacts its business over HTTP, and you're not using URLs as the basic representations of your application's resources, you need to just stop now. You're hurting your clients, you're hurting the Internet, and you're hurting me.
Hi, I'd like you to meet my friends: HTTP 401 Authorization Required and HTTP 403 Forbidden. They're bult in to the protocol your app is using, so the libraries you're developing with had better support them, and they're extensible to use pretty much any authentication scheme you want to use. And then once somebody's authenticated into your system, you can -- gasp! -- let them fetch things using standard HTTP methods like GET!
Actually, I think you're working with people who've never developed web applications before, and rather than have them learn the new platform they'll be developing on you want to make it behave just like what they're used to. Fair warning: it won't be long before doing business that way will put you out of business.
Imagine if I decided to move from web development into desktop apps, and the first thing I did was write a local HTTP server that my app talked to for all its storage and retrieval instead of using native filesystem functions. I'd look pretty damn silly, wouldn't I? Well, just imagine how damn silly you must look...
Not really. The idea behind Rails' scaffolding is to give you basic, unstyled example CRUD views that you're expected to throw away once you've built customized ones; they're a starting point. Django's admin application, on the other hand, is a production-ready, fully-styled application with manipulation of related objects, fancy JavaScript widgets (e.g., date and time selection, automatic population of URL "slugs", etc.), an auth system and full logging of user actions. And when I say "production-ready" I mean "production-ready": many Django applications in the wild find the stock admin application more than sufficient for their needs.
And the generic views really aren't scaffolding, either, because they're not meant to be thrown away and replaced with something you develop yourself, the idea being that some tasks (CRUD, lists of objects, detail of a particular object, date-based navigation, etc.) are so common you shouldn't have to write views to do them. So Django has a full set of generic views for these tasks, and all you have to do is route URLs to them for input and hook them up to page templates for output. I think the apparent similarity here comes from the nature of Rails' templates -- in Rails, the "view" and the "template" aren't separate, and you just have a "view" that's a mixture of HTML markup and embedded Ruby code. Django separates application logic from the templates, so a view in Django is pure Python, and returns a dictionary of variables and values to be used inside a template with deliberately simple syntax.
It's bad for publicity, but a lot of development with the new generation of web frameworks is taking place behind corporate firewalls and under NDAs. Some frameworks do advertise lists of public websites which use them, though. :)
Except he got more than a few things wrong. To pick one example, he seems to be under the impression that Django doesn't support i18n/l10n when, in fact, we ship all the core Django applications with support for twenty-odd languages, and Django uses an extensible gettext-based system to make it easy to translate third-party apps and add new languages. We even include an i18n JavaScript library to make translation strings available to JS code. Our admin app even has a setting that chooses which language to render a page with based on the incoming Accept-Language header.
Moral of the story: nice video, but the guy hasn't necessarily done his homework.
Many-to-many relationships? Rails may or may not have them (been a while since I last played with it), but Django most certainly does. We don't have "scaffolding" (though somebody's submitted a patch to do something similar), but we do give you a ready-to-go administrative interface built from introspecting your models, and it's got some nice tricks for displaying many-to-many relations. We also give you a lot of other useful stuff like generic views pre-written to handle most common tasks (CRUD, date-based object listing and navigation, etc.) so you just need to write templates and hook up to them; Django was extracted from the codebase of several large content-oriented sites, so it's really good at that sort of thing.
Disclaimer: I work for the company which originally developed Django. Though I didn't work there at the time; I applied because I liked Django and wanted more opportunities to work with it.
Then why not take advantage of features of the Internet? If you're using HTTP, then every one of your content objects can be a resource accessible via HTTP GET at a unique URL, but too many "web application developers" fail to recognize that this gives them transparent, universally-usable storage and retrieval, programmatically accessible from pretty much every language on Earth, essentially for free. When you move into a new operating environment, you should adapt to that environment instead of trying to shoehorn another environment's worldview into it.
I place the blame squarely on Prototype. Application developers should never have to worry that someone else has snuck in and modified the core language's behavior without their knowledge, because down that path lie nightmares of coupling and maintainability which are best avoided.
The "ping" attribute was proposed by Ian Hickson on 21 October of last year, as a quick search in the WHAT-WG mailing-list archive would have shown if you'd bothered.
In his posting, Ian explaings the reasoning behind the attribute. You can do it with onclick, but then again you could manually write out every page of a dynamic website instead of using a CMS to automate the process.
You're absolutely right, you know. Having a close button on every tab completely removes or negates absolutely every single benefit of tabbed browsing, without hope of recovery.
Or not. People seem to use Safari, Opera, Galeon, and other browsers that do this, so maybe it's not quite the "ruins tabbed browsing" problem you think it is...
You and me both.
I think that in the case of web frameworks, the OS analogy is apt; most OS APIs provide a lot of functionality that a particular application will never use, but in order to be general-purpose enough to support all the applications that will run on the OS, all that functionality needs to be there. Or one could quote the old adage about MS Word, that 90% of the features are used by only 10% of the users, but it's a different 10% for each feature.
And, FWIW, Rails isn't nearly as bad as, say, some of the Java frameworks when it comes to cluttering up your symbol tables with tons of methods you probably won't use ;)