If yer significant other is one of those barely hygenic linux freaks with the overly long finger nails, why not find him another chubby goth chick like yourself to roll around in the bed with on that oh so special corporation created holiday?
It's something he'll probably never have the chance of experiencing again and it'll save you a hundred bucks.
The technology is designed to enable secure document transfer between trusted parties. For instance, documents containing trade secrets or engineering specs for a company's latest greatest apps. The creator of the document can secure it so only specified people can read it, limiting potential leaks outside of the company, or the document falling into the wrong hands.
It is not enabled by default and it requires an internal infrastructure to implement (Windows Server 2003 with Windows Rights Management) so the average joe blow isn't going to even be able to use it.
As for "competing products" not being able to read these secured documents, well that's the whole point right? If you're publishing secure documents, you're securing them for a reason, and you're only going to want those who can read it to read it.
There could be an argument for Microsoft to publish an open standard for interoperation, but this is America, not a socialist state, so that argument is a little weak.
Personally, I think this is a cool feature, and one I'm personally going to be using for my day to day work.
A site I launched last year, written entirely in.net, handles about 110-200 visitors a minute on a single cpu 3ghz machine. It's not a very database intensive application, but it does do a lot of file i/o as most of it is built on top of XML for data storage.
CPU usage averages about 30% and memory holds constant. Uptime is about three months and the only time we really have had to reboot is installing updates and critical fixes.
The site was a complete rewrite of an older site that had been done in perl and ran on redhat. The average cpu load on that box was around 80%.
For the database aspects, it really depends on how you architect the thing. Using SqlDataReaders, for instance, is N-times faster then using the standard disconnected DataSet. It also requires slightly more code. Caching the data is also important, as well as caching the site in general.
My experience with.NET has been nothing but positive. It's seriously cut down on development time and has been more reliable that you'd expect.
You write new "tags" in.NET by extending from an existing "control" or writing one based on System.Web.UI.Control.
The design is similar to what one would do in writing standard UI controls for desktop applications. Furthermore there is support for templating, child controls, etc.
> were written in VB *shudder*, but when dotnet > was released I switched immediately to C#. > C# does some things right that Java > didn't do too well on, but those are honestly > pretty rare. IMO, C# is very much like an > immature version of Java. That being
Pass around whatever your smoking, I'd like some.
Delegates, true properties, attribute based programming are all vast improvements over anything you get with Java. Because you come from "VB" I can understand where you wouldn't understand or use all of C#'s features, but don't tout your ignorance of them as fact.
You have custom script engines already built into the.net framework. I can load and compile "scripts" on the fly with a few lines of code (VB, JScript, C# or any other.net language). You can load those scripts in your current application domain, or isolate them in a seperate domain for increased security.
If you load them into your current application domain, those scripts have direct access to your object model, plus they are "compiled" to the CLR before execution so they'll execute just as quickly as the rest of your app.
Agreed, but the openness of the language and the Java community allows for others to come up with even better solutions [apache.org]. Downloading the J2SE sdk and Tomcat is cheaper than buying Visual Studio.NET from a development standpoint.
Why is.NET any different? You could roll your own if you wanted. ASP.NET is written in.NET. Also, you don't need visual studio to do asp.net, there is the web matrix, C#studio and notepad. And if you don't want MS's.NET runtime, go MONO
You're not supposed to be able to. That's not what HTML does.
HTML is a content language. The whole beauty of it is that the final presentation is NOT THE DESIGNERS RESPONSIBILITY. No web site will look the same on all platforms - that's the point.
That's all fine and good in a utopian environment, but that simply isn't a realistic target. There are layers of indirection that cloud and complicate the development of a website, and although the developer might be educated, bubbling that education up through the designers, the art directors, the projects managers, the account people and, finally, the client would come at significant cost, both economic and strategic.
The truth is that intentions of implementation have little real world bearing on it's actual use. Screw-drivers were intended to turn screws, but people use it for all different purposes from opening cans to picking teeth to scratching their backs. Intention can never surpass need, and if you need this object or technology to perform a function, you will find a way to make it do so.
This leads me to my gripe that the "standards" body developing these "standards", few of these people come from the trenches, and few understand how people really need and want to use HTML, so of course we have this problem of forcing a round peg through a square hole. The standards committees are comprised mostly of academics and browser engineers, let's see some major web developers up in that hizzy!
The people you are talking about are not 'web designers' - cannot be, because they don't have a clue what the web is. If you cannot accept the fact that your content can be presented different ways (including to blind people) as appropriate to each individual client, you have no business on the web. Make.pdf files or something.
You say don't tell you to get with the "real world", but, well, "get with the real world". What you are describing is good for an academic view of the world, but academics and reality rarely ever cross in any sort of truthful or useful manner. The fact is you can preach this until you're blue in the face, but your understanding isn't nescessarily the whole truth on the matter, nor should it be. People use technology for whatever needs they think it can solve, so people are going to use HTML to solve problems it may or may not have been intended for, and the world is going to need to adapt and accept this.
I think Zeldman is an alarmist and a bit of show man, I don't think the issue is these sites not keeping with the standards, but the standards not keeping up with the needs.
I've always considered Zeldman to be one of those self-proclaimed know-it-alls who has had little real industry experience in high volume, high technology web-sites. Most of his portfolio is brochure-ware that looks like it was done by a team of one. So I've always considered his belly-aching a little simplistic and, frankly, unrealistic in current web development scenarios.
It's easy to lament the fact that these sites aren't standard, but there are clearly reasons why most of these sites don't fit his vision of standards compliance.
For one, most sites don't have the budget to develop to standards. It's much easier to code to specifics and use non-standard work-arounds where possible then to boil everything down to the least common denominator (which standards are supported by whom). When I say easier, I mean that years of experience have instilled intimate knowledge in the seasoned web developer that almost comes as instinct now.
Secondly, all of these "standards" are interpreted differently by the different browsers, so you can't insure consistent look and feel without kludges.
Third, most of the foundations for these sites were layed out before coding to a standard was even possible, and when the mindset was not focused on any sort of standards compliance.
Finally, I've always thought that they made writing to standards compliance sound easier then it actually is, because even though it's called a standard, it rarely exhibits standard and consistent behavior across the various platforms. Most art directors and graphic designers - specifically those that migrated from print or traditional design - tend to be exteremly unyielding in the way their designs are interpreted on the web, leaving developers with few options that are fully supported by these so-called standards.
Personally, I think Zeldman needs to spend some time in the trenches working on a large site with a large development team under real deadlines for real clients. Things are rarely ideal in these circumstances.
The majority of professional web developers make every attempt at keeping the pages working across multiple platforms and multiple browsers. Any dev shop worth a lick of salt has this built into their QA process.
I personally use what I can on the server-side to adapt pages to the browser viewing them. For most modern browsers, this only requires slight changes to insure consistent look and feel, but for netscape 4.x some major tweaking might be required. For instance, if I have any DHTML that is required, I try to make sure the designers have designed any DHTML elements so that their is a fallback mechanism that works if the browser viewing the page doens't have javascript enabled, or their DHTML implementation is too buggy to bother with.
Being a microsoft shop, we use asp.net for development and it's proven quite easy to develop a set of custom server tags to enable this sort of adaptivity. It's really as simple as:
Additionally with asp.net (as well as jsp) most of your page's UI elements are probably written as "controls" (or widgets) and you write those to degrade to lesser browsers, and give the full feature set to the capable ones.
In the end, it's all about rigorous QA and deciding what works best for what platform and making those changes accordingly.
Conspiracy theories aside, IE was a real boon to the advancement of DHTML for user interface in web pages. While netscape 4.x was choking to death, IE enabled developers to do a lot of new things rather easily. Unfortunately, this all occured during the web boom and a lot of developers were lazy or hurried and didn't take the time to strategize for multiple browser/platforms.
There are pages here that discuss nuclear propulsion techniques and demonstrates their superior potential over chemical rockets. Interesting read...
Re:Was that so complicated?
on
What is .NET?
·
· Score: 1
Swing uses the bare minimum of native components and creates its own widgets. This gives you the power to do things you can't do with Windows (and ComCtl32), Motif, Mac, whatever. Swing is not slow in and of itself: try running the program for a while and accessing all the GUI functionality, then all of the classes will be loaded and the JIT will have compiled most bytecode, and you can use Swing happily.
You obviously have never written an app for Windows with anything other then Java. It's relatively easy to make your app look like anything you want and there are a host of third party components/libraries that let you swap look/feel fairly easily. And if nothing strikes your fancy, you can write your own controls with their own look and feel.
Delphi is a great environment for this sort of programming
Re:dotNet is not standard
on
What is .NET?
·
· Score: 1
.net is built on open standards... the CLI is ECMA moderated, the language specs are all standardized, etc.
The only thing that isn't are pieces specific to windows such as the windows forms framework and related. If you read the article, the author hit a very important point when he said Microsoft's implementation isn't open, but it's based on open standards.
As for your second question, yes there are lots of things that it can do with far more speed (in terms of development cycle) then Java. If I'm writing a desktop app in Borland Delphi and want to use some.net framework classes... it's easy as pie to do this and vice-versa. The only way to do this in java is through JNI and that's such a crappy way to go it's worthless unless you're stuck using legacy code in a java app.
In terms of writing web services and web sites with asp.net - which is what I do mostly - I can tell you the framework classes open the doors wide on all kinds of stuff that previously was far more difficult to do. Writing a web service is a five minute excercise and deployment is instantaneous... no dinking around with a million XML files like with J2EE.
It's got it's problems, but if you look at it from a pure techincal perspective, I can't see how people, windows developers specifically, aren't going to flock to this.
You're ignorance will get the better of you in the long run. ASP.NET applications work fine for every browser under the sun (no pun intended).
If yer significant other is one of those barely hygenic linux freaks with the overly long finger nails, why not find him another chubby goth chick like yourself to roll around in the bed with on that oh so special corporation created holiday?
It's something he'll probably never have the chance of experiencing again and it'll save you a hundred bucks.
Nice to see Swing still looks like shit.
Everything I've read has been to the contrary of what you are stating.
Can you point to anything to substantiate your claims?
I didn't laugh once, no denial here.
You guys even bother reading the article at all?
The technology is designed to enable secure document transfer between trusted parties. For instance, documents containing trade secrets or engineering specs for a company's latest greatest apps. The creator of the document can secure it so only specified people can read it, limiting potential leaks outside of the company, or the document falling into the wrong hands.
It is not enabled by default and it requires an internal infrastructure to implement (Windows Server 2003 with Windows Rights Management) so the average joe blow isn't going to even be able to use it.
As for "competing products" not being able to read these secured documents, well that's the whole point right? If you're publishing secure documents, you're securing them for a reason, and you're only going to want those who can read it to read it.
There could be an argument for Microsoft to publish an open standard for interoperation, but this is America, not a socialist state, so that argument is a little weak.
Personally, I think this is a cool feature, and one I'm personally going to be using for my day to day work.
They are only blocking OLDER versions of the protocol. The article misrepresented the intent of the bulletin.
A site I launched last year, written entirely in .net, handles about 110-200 visitors a minute on a single cpu 3ghz machine. It's not a very database intensive application, but it does do a lot of file i/o as most of it is built on top of XML for data storage.
.NET has been nothing but positive. It's seriously cut down on development time and has been more reliable that you'd expect.
CPU usage averages about 30% and memory holds constant. Uptime is about three months and the only time we really have had to reboot is installing updates and critical fixes.
The site was a complete rewrite of an older site that had been done in perl and ran on redhat. The average cpu load on that box was around 80%.
For the database aspects, it really depends on how you architect the thing. Using SqlDataReaders, for instance, is N-times faster then using the standard disconnected DataSet. It also requires slightly more code. Caching the data is also important, as well as caching the site in general.
My experience with
You write new "tags" in .NET by extending from an existing "control" or writing one based on System.Web.UI.Control.
The design is similar to what one would do in writing standard UI controls for desktop applications. Furthermore there is support for templating, child controls, etc.
It's way beyond JSP.
The metadata, auto-boxing, enhanced iteration looks like catch up with C#'s attributes, foreach, etc.
Where are true properties though?
> were written in VB *shudder*, but when dotnet
> was released I switched immediately to C#.
> C# does some things right that Java
> didn't do too well on, but those are honestly
> pretty rare. IMO, C# is very much like an
> immature version of Java. That being
Pass around whatever your smoking, I'd like some.
Delegates, true properties, attribute based programming are all vast improvements over anything you get with Java. Because you come from "VB" I can understand where you wouldn't understand or use all of C#'s features, but don't tout your ignorance of them as fact.
You have custom script engines already built into the .net framework. I can load and compile "scripts" on the fly with a few lines of code (VB, JScript, C# or any other .net language). You can load those scripts in your current application domain, or isolate them in a seperate domain for increased security.
If you load them into your current application domain, those scripts have direct access to your object model, plus they are "compiled" to the CLR before execution so they'll execute just as quickly as the rest of your app.
Unfortunately, Adobe owns some patents which will always cripple GIMP from hitting the professional expectations Photoshop has set.
Chicken Little anybody?
Why is .NET any different? You could roll your own if you wanted. ASP.NET is written in .NET. Also, you don't need visual studio to do asp.net, there is the web matrix, C#studio and notepad. And if you don't want MS's .NET runtime, go MONO
You're not supposed to be able to. That's not what HTML does. HTML is a content language. The whole beauty of it is that the final presentation is NOT THE DESIGNERS RESPONSIBILITY. No web site will look the same on all platforms - that's the point.
That's all fine and good in a utopian environment, but that simply isn't a realistic target. There are layers of indirection that cloud and complicate the development of a website, and although the developer might be educated, bubbling that education up through the designers, the art directors, the projects managers, the account people and, finally, the client would come at significant cost, both economic and strategic.
The truth is that intentions of implementation have little real world bearing on it's actual use. Screw-drivers were intended to turn screws, but people use it for all different purposes from opening cans to picking teeth to scratching their backs. Intention can never surpass need, and if you need this object or technology to perform a function, you will find a way to make it do so.
This leads me to my gripe that the "standards" body developing these "standards", few of these people come from the trenches, and few understand how people really need and want to use HTML, so of course we have this problem of forcing a round peg through a square hole. The standards committees are comprised mostly of academics and browser engineers, let's see some major web developers up in that hizzy!
The people you are talking about are not 'web designers' - cannot be, because they don't have a clue what the web is. If you cannot accept the fact that your content can be presented different ways (including to blind people) as appropriate to each individual client, you have no business on the web. Make .pdf files or something.
You say don't tell you to get with the "real world", but, well, "get with the real world". What you are describing is good for an academic view of the world, but academics and reality rarely ever cross in any sort of truthful or useful manner. The fact is you can preach this until you're blue in the face, but your understanding isn't nescessarily the whole truth on the matter, nor should it be. People use technology for whatever needs they think it can solve, so people are going to use HTML to solve problems it may or may not have been intended for, and the world is going to need to adapt and accept this.
I think Zeldman is an alarmist and a bit of show man, I don't think the issue is these sites not keeping with the standards, but the standards not keeping up with the needs.
I've always considered Zeldman to be one of those self-proclaimed know-it-alls who has had little real industry experience in high volume, high technology web-sites. Most of his portfolio is brochure-ware that looks like it was done by a team of one. So I've always considered his belly-aching a little simplistic and, frankly, unrealistic in current web development scenarios.
It's easy to lament the fact that these sites aren't standard, but there are clearly reasons why most of these sites don't fit his vision of standards compliance.
For one, most sites don't have the budget to develop to standards. It's much easier to code to specifics and use non-standard work-arounds where possible then to boil everything down to the least common denominator (which standards are supported by whom). When I say easier, I mean that years of experience have instilled intimate knowledge in the seasoned web developer that almost comes as instinct now.
Secondly, all of these "standards" are interpreted differently by the different browsers, so you can't insure consistent look and feel without kludges.
Third, most of the foundations for these sites were layed out before coding to a standard was even possible, and when the mindset was not focused on any sort of standards compliance.
Finally, I've always thought that they made writing to standards compliance sound easier then it actually is, because even though it's called a standard, it rarely exhibits standard and consistent behavior across the various platforms. Most art directors and graphic designers - specifically those that migrated from print or traditional design - tend to be exteremly unyielding in the way their designs are interpreted on the web, leaving developers with few options that are fully supported by these so-called standards.
Personally, I think Zeldman needs to spend some time in the trenches working on a large site with a large development team under real deadlines for real clients. Things are rarely ideal in these circumstances.
What is it they say about armchair coaches?
Use dataexpress, does the exact same thing in a much smaller footprint.
Are you totally retarded? They use the same debugger, incidentally, written in Delphi.
And, once Mono gets going, you'll probably want what it offers as well.
Of course, if you don't code and aren't in need of a framework like this, then you'll probably not want it.
It's been a massive boon to my productivity in the last six or seven months.
The majority of professional web developers make every attempt at keeping the pages working across multiple platforms and multiple browsers. Any dev shop worth a lick of salt has this built into their QA process.
I personally use what I can on the server-side to adapt pages to the browser viewing them. For most modern browsers, this only requires slight changes to insure consistent look and feel, but for netscape 4.x some major tweaking might be required. For instance, if I have any DHTML that is required, I try to make sure the designers have designed any DHTML elements so that their is a fallback mechanism that works if the browser viewing the page doens't have javascript enabled, or their DHTML implementation is too buggy to bother with.
Being a microsoft shop, we use asp.net for development and it's proven quite easy to develop a set of custom server tags to enable this sort of adaptivity. It's really as simple as:
<ilab:Browser Browser="Netscape" Major="4">{
</ilab:Browser>
<ilab:Browser Browser="Default" >
{
</ilab:Browser>
Additionally with asp.net (as well as jsp) most of your page's UI elements are probably written as "controls" (or widgets) and you write those to degrade to lesser browsers, and give the full feature set to the capable ones.
In the end, it's all about rigorous QA and deciding what works best for what platform and making those changes accordingly.
Conspiracy theories aside, IE was a real boon to the advancement of DHTML for user interface in web pages. While netscape 4.x was choking to death, IE enabled developers to do a lot of new things rather easily. Unfortunately, this all occured during the web boom and a lot of developers were lazy or hurried and didn't take the time to strategize for multiple browser/platforms.
There are pages here that discuss nuclear propulsion techniques and demonstrates their superior potential over chemical rockets. Interesting read ...
You obviously have never written an app for Windows with anything other then Java. It's relatively easy to make your app look like anything you want and there are a host of third party components/libraries that let you swap look/feel fairly easily. And if nothing strikes your fancy, you can write your own controls with their own look and feel.
Delphi is a great environment for this sort of programming
.net is built on open standards ... the CLI is ECMA moderated, the language specs are all standardized, etc.
.net framework classes ... it's easy as pie to do this and vice-versa. The only way to do this in java is through JNI and that's such a crappy way to go it's worthless unless you're stuck using legacy code in a java app.
... no dinking around with a million XML files like with J2EE.
The only thing that isn't are pieces specific to windows such as the windows forms framework and related. If you read the article, the author hit a very important point when he said Microsoft's implementation isn't open, but it's based on open standards.
As for your second question, yes there are lots of things that it can do with far more speed (in terms of development cycle) then Java. If I'm writing a desktop app in Borland Delphi and want to use some
In terms of writing web services and web sites with asp.net - which is what I do mostly - I can tell you the framework classes open the doors wide on all kinds of stuff that previously was far more difficult to do. Writing a web service is a five minute excercise and deployment is instantaneous
It's got it's problems, but if you look at it from a pure techincal perspective, I can't see how people, windows developers specifically, aren't going to flock to this.
Some of the biggest morons I've ever worked with had 4.0 GPAs from places like CalTech and MIT. Some of the sharpest had no college education at all.