Wow, what a sad day for the industry. I guess this shouldn't come as a big surprise since we've been hearing about his health for some time now.
I also know it's been said many times, but Steve Job was truly visionary. The last decade, and particularly since the iPad has been released, have been tremendous in terms of the amount of influence he has made (though that's been the case most of his career at Apple). Over the past few years, I slowly started picking up Apple technology. As a long term PC guy this was a tough thing to do and in hindsight, I wish I'd started earlier! I hope his legacy lives on. One can only wonder how the face of computing would have changed if he had another 10 years.
Here I am typing this on my first ever Macbook Pro. I haven't logged in for a few years here on/. but thought this story was worthy of a post. Way to go Steve, Rest in Peace!
Didn't you read some of the articles about overriding ASP.Net JavaScript generation so it would be cross-browser (i.e., some of the JavaScript that ASP.Net is IE-specific, I think primarily regarding MS additions to the DOM).
Yeah, ASP.NET today generates simple javascript stuff for validating drop downs without doing post backs and that is about the extent of it. AJAX is more geared toward "more advanced" stuff, like loading a drop down based on a value that you pick in another drop down. In that case, AJAX uses an xmlhttp object to connect to a web service, grab the result, and update a control on the screen w/o having to post the page back- which is traditionally done on the server with ASP.NET.
For what it's worth, Live.com (and Start.com before it) uses Atlas. Building Gadgets for Live.com/Start.com is a good way to get your feet wet with Atlas, though they could do a better job of providing documentation.
Cool, thanks for the links. I haven't played around enough with Atlas yet, but it definitely looks promising. It may be "good enough" to switch over from the web service behavior we've been using (w/ our own custom client side functions).
It's nice to see that the "rest of the world" is finally seeing the importance of moving to decent web based user interfaces. However, the concept of AJAX has been around for quite some time. I was using a technology called "Remote Scripting" back in the late 90's that allowed you to hit server side pages via a "proxy" java applet, and then update your page however you wanted with javascript. Granted, it was pretty ugly code, but it made for a heck of a UI. No more annoying "flickering" on the web page, as the users used to call it.
I was quite displeased when ASP.NET came out and really put everything on the postback paradigm. They tried to cobble together something called "smart navigation" which was basically loading the page in a hidden frame and then updating the changes. What a waste! Instead, I was using the web service behavior. Downside is it only works with IE.
Now there is something on the.NET platform that Microsoft is making called "Atlas". It builds on AJAX but allows a developer to write ASP.NET server controls that render AJAX-ish code. At least that's the concept, I believe. Will be nice to see how it pans out.
Having said all that, I'm glad that the rest of the world is catching up. Gmail was a big step in the right direction showing people the kind of functionality that AJAX can offer (though I don't think it's using ajax, I could be wrong though). Web apps are definitely "where it's at". I think we will begin to see the next evolution of web applications with this technology.
Where abouts in Ohio? I'm in Northwest Ohio. There is wireless internet for rural areas- about 1 mbit, for about $50 a month.
I'm in an area where we have some competition for cable co's, though DSL is not offered "yet". I'm paying about $100 / mo for 4.0 mbit down / 384 Kb up along with HDTV and VOIP through a company called Buckeye Express. I used to have DSL through SBC at my old house that was about $20/mo. Not too bad.
SAme here, sliders was an excellent series. I thought it had a ton of potential. I even remember one episode that had a matrix like theme where people were walking around with these VR goggles but living in an alternate reality. There were several episodes like that, that eventually ended up being used in later movies. The chick in it was really hot, too (don't remember her name). Maybe they will remake that one some day though the idea isn't as fresh as it once was.
isn't calling employees "resources" part of the problem that leads to the acceptability of the lack of loyalty to staff shown by many short-sighted companies?
I think a lot of it depends on the company. At the company I *used* to work for, they threw that term around like you weren't a person, but equated you to a piece of machinery that cranked out code and it made you feel low. When I first started hearing the term at the company I am now at, I was worried because of my previous experience- but I noticed it is mostly used only when talking about projects. I think you get into trouble when you use it to describe a person, their training needs, their effectiveness, etc.
Even so, it really seems to be the language of business when it comes to management. It does have an impersonal feel to it, but I'm used to it now.
Is it really "technology bounceback" or a new term for "dotcom bubble reinflation" ??
Not that it would be a bad thing.
No doubt, a good reinflation would be a nice breath of fresh air for those of us still in IT. I personally think IT is currently undervalued in many cases and a reinflation is necessary to retain good IT workers. When the economy does bounce back, I think we will see a lot of turnover- ie, IT going to the companies that do offer the good benefits again.
I entered IT when the bubble was getting going (early 98) and have been in since. For the past two years, the benefits of being in IT have certainly decreased- lower raises (the days of 10% minimum raises are gone!), having to "coordinate" work with India, doing the work of three people, etc. I don't think our IT department budgeted for training this year- which is sad, considering training is required to do you job-- you basically need to get it outside work (I do this anyway...). We're also hiring less local talent (in fact we can only hire new resources in India, but can still replace resources locally as needed). Sometimes I am convinced corporations are punishing IT departments for many of the indiscretions committed in the golden days. The sad thing is, our IT department has always been conservative and didn't get into the hype of the dot-bomb. I think it's just that many corporate execs still seem to have a bad taste in their mouths.
I disagree, and I think that's perpetuated by a number of bad habits, bad practices and simple job protectionism coming into play. It's much easier to keep a job if I'm seen as the only "craftsman" who can maintain a system.
There is some truth to that. In an ideal world, it may be possible to build a system once that could do everything perfect. But given the speed and chaos at which business requirements, applications, and technology change it is unlikely that the "art" aspect of software development will change any time soon.
Great link- I used a lot of the Standish report for some masters work.
Time and maturity are important considerations, but I don't think software development is totally an "engineering science" that can be likened to traditional engineering (mechanical, civil, etc.) Primarily because software development is so "chaotic" in nature. The chaos is not due to the lack of maturity, but more because of the human element. Simply put- software does not have the same level of objectivity as a bridge or sewer system might have.
I find it interesting that "methodology" was the biggest risk driver for a project.
I think the true crux of the problem with software development lies in understanding requirements. A methodology will most definitely HELP find the requirements, but I don't think it's directly the biggest risk driver.
In my experience the biggest problem is getting the users engaged in the requirements gathering. This is the most critical piece- no matter what methdology you use (and they will come and go) you still need to make sure that you understand the requirements. In most business environments, software development tends to a discovery process. In some cases the users can visualize a system and what it should look like, in others they cannot and it just may take a lot longer time. In that case, expectations should be properly managed by the stakeholders. PM's come in to play and should explain what is likely to happen- requirements will change, development or design may take more time, etc. Investigate other options for requirements gathering and understand not all of it may be able to be done on paper.
I've found that most business applications work best when I have users who have had some level of experience with Information Systems, who are committed to walking through what the system should do, and have support from management to do so through the entire development cycle. Technology and development tools are usually the issue, especially if you have competent developers.
This is incorrect, DOM 3 Load and Save was finalised back in April, and it has been implemented by multiple browsers already. You still have to mollycoddle Internet Explorer of course, so you may not think that it's worth your while to implement the W3C approach, but that's your call.
Unfortunately, Internet Explorer is still the ruling king in corporations and the Internet. So yeah, I am going to implement it how IE does. Also, this spec is pretty far behind the times. IE has had this functionality for over 3 years.
I love how everyone in the Linux community expects MS to drop everything they are doing and adopt this new W3C standard because it's a STANDARD. Therefore it "must" be better than what MS has been doing. I love it! So what about all of us who have written code already because there was no W3C standard?? Should we all be good programmers and go back and change our code just because? Heh, not in the world I work in...
Anyway, IE hopefully will end up implementing the W3C spec eventually, but April 2004 in the world of corporations (at least those that make money over the Internet) it is still relatively new. In your environment maybe.. (I take it you are either at a University) but not mine.
I've been using the XmlHTTP stuff in IE for a while now, in the form of "Web Service Behaviors". MS makes it pretty easy to use, and gives you support for both synchronous and asynchronous web services calls from the browser. Pretty cool stuff.
Of course, being a good MS developer, one should always look into the issues you posted...
1. How secure is this? IOW, does it rely on anything at all other than JavaScript on the client side, or does it hook into the OS on some level? If it does, how well is it isolated from the more dangerous bits in the OS?
It relies on JAvascript and the Browser. The browser uses an activeX XmlHTTP object. This is used in the same process as the browser runs in.
The security hole that I know of is not going to be on the client. If anything there is a whole from client to server in the communication. If you are using HTTPS or a custom encryption to communicate it's probably not a big deal. The only other big deal is if you are using public web services and don't secure your WSDL. That in my mind is the biggest issue. The behavior needs to have a WSDL in order for it to set up a proxy. WSDL by nature means you can get a listing of all the methods and parameters that a web service uses. So.. don't put anything super secure on your web service that a browser is going to be talking directly to.
2. If it does require anything other than JS - even if it does only require JS - is it Windows only, or have our good friends at Microsoft realised why a goodly portion of the tech community is, ummm, hesitant to accept thier 'vision' of what computing should be?
If you do a little digging you'll see that remote web service calls from the browser are still a relatively "new" thing. There is no W3C standard as of yet. There are other browsers (Mozilla, etc.) that have a similar implementation. For now, it's just like everything else.. wait until a standard emerges and the next version of the browser (or service pack) will probably implement it along with some "extensions".
One thing to be aware of- IISLockdown, while very secure, also causes a pretty significant hit on scalability. If you are running a huge site then be careful if you install this tool. I'm not sure what the impact on scalability is for the proposed fix just yet.. I'm guessing it's probably not as much overhead though.
Actually, that's a good idea, but the actual problem occurs before your application code runs. Since that is the case you need to code an event sink that is stored in the global.asx file, which is (or can be) a part of every.NET application. It's really easy to fix. I already patched a few of our sites. Anyone using code-behind will have to recompile to make the fix, other wise you can dump it right in the asx file and it will compile behind the scenes. I'll post more info in a JE soon.
In my experience, this is a difficult question to answer. There are many factors that you should consider in making a decision to use all stored procedures or not.
First, every business has different needs. Every software development group is also different in what they can or cannot provide. There are camps on both sides- many people in the database discipline will say "put everything in the database" while hard code developers will sometimes opt for queries in code.
Some considerations:
1) Consider the needs of your application. Is there a good chance your application will need to talk to another database platform or backend at some point in the future? This could be an argument for not using stored procedures. AS far as centralizing business logic goes, that can be done in just about any tier.
2) Where is your current bottleneck? How possible will it be to scale out your database server? If you are in a web farm scenario, your database server may be under significant load. Putting more logic on the database server can be a lot more expensive- it is typcially a lot cheaper to sacrifice performance on the backend for scalability. In other words, if you can keep your database server relatively load-free you can always add more web servers. I currently support a site that has over 2000 concurrent users at any given time, and currently our DB is the biggest bottleneck. It is a lot cheaper to cluster web servers than DB servers, since the DB is centralized and web servers can be duplicated easily.
3) Consider the experience of your staff and the culture of your IT department. If you have a lot of developers/dba's that are used to programming with stored procedures, and management is used to that paradigm, it may be difficult to change architectures without a compelling reason. "If it ain't broke don't fix it".
I'm sure there are other considerations, but those are probably the most three important ones I can think of right now.
1: Microsoft has been convicted of antitrust violations. Hence why.net can't be used by linux programmers. What's stopping them? The go-mono project is quite active- I get at least 50 emails a day from linux programmers that are using.NET on linux. There is also.GNU and some other projects. Rotor is only for "educational purposes" but it runs on OpenBSD.
2: Blaster. The most popular platform, ran by the most people in the world, etc. is bound to have security holes that get exploited. Unfortunately when 95% of the people out there don't know how to patch, these are blown way out of proportion. One company can only do so much to prevent the problems- anything else and you get complainers (see point #4).
Many linux groups are still nitpicky crazy people who instead of agreeing and copromising, they bicker. Even more are lazy, or greedy, or just plain stupid. I've presented at LUG's and I would somewhat agree with this point. There are some people that are just interested in getting things work, but many of them are hecklers, complainers, etc. It's just the sub culture. I used to be "on the other side of the fence" and I know the mindset. Once I graduated college and started working with business, my perspective changed quite a bit. People are drawn to anger/hate/etc. and unfortunately leaders in the linux community help foster this so it continues to pervade.
4: Open source people see Microsoft's code signing as a way to enact DRM, which is a polite way of saying they want total world domination. Many linux guru's like the idea of code signing, they just don't like Microsoft and they have good reasons.
Exactly. MS starts implementing security to eliminate things that happen in #2, and now the complaints start rolling in. No matter what MS does there will always be naysayers. They will never be satisfied.
5: Linux, netware, and other operating systems are still used for servers more often than Microsoft's software. MS's software is only used on desktops because everyone knows it. I'v used KDE on suse 8.1, it works well for anyone accept power users and I see no reason for ma n' pa to spend $300 on a new copy of winxp so they can check their e-mail.
In most companies that I have worked in or with, Linux tends to be used primarily for non-critical systems. Solaris is used on any other *nix based system for critical things (eg. production oracle databases), and the hardware cost is astronomical in comparison. We are converting to Win2K servers. The license cost for a business is not what a consumer would pay, in fact it is significantly less (ex-$100 instead of $300 for XP). Most new PC's that companies order (ie, dell) come with WinXP anyway.
6: Coding tools for linux exist that are open source and that work well. Not everyone is coding in C..Net isn't unique
Ok, as a.NET developer I definitely have some comments on this one. One of the biggest reasons I "switched" to MS was because of the development tools available. Not only that, but also the support, and the willingness of the developer community (tons and tons of support- just do a google search), as well as Microsoft. There are MS dev leads that help support developers FREE of charge. Sure, the cost of the tool can be pricey, but you aren't just buying the tool. Also, I have never found a tool that has all the needed capabilities/performance/integrated environment of VS.NET in an open source project (for any language). Some open source Java tools come close, but they tend to be really slow and lacking one or two key features that I need to be productive.
7: Linux is known for it's efficiency. On a server, efficiency > ease of use. Ms's software was designed for idiots,
I don't think it was designed for "idiots" but I agree that there is definitely a level of abstraction that MS unnecessarily gives the sys admin that ca
.NET is a 10-year hedge against that. Thanks to.NET, MS has the ability to ditch Windows in the future. As Windows fades, MS can be assured that its other cash cows - MS Office, the backend products, etc are still viable and dont need rapid porting to a new platform....At that point - 5 years, 10 years, etc - in the future MS will have successfully allowed themselves to be #1 regardless of hardware vendor, architecture, operating system, and even written language!
From what I understand about the future direction of.NET, I think you are right on the money. I've spoken with many technology "evangelists" (both Microsoft and non-microsoft) and here is what they see:
1).NET CLR is going to be come the next operating system. Windows will run on top of the CLR. Similiar to how we went from DOS to running Windows to Windows running DOS (when necessary).
2) The move towards.NET becoming the base OS is evident if you know about "Longhorn", the next version of windows. The entire win32 API is going away and being repalced with the.NET framework (which will certainly be extended in it's present state to cover everything).
What this means to me personally- I can't go wrong getting into.NET. It's coming one way or the other. Projects like MONO are helping it exist on other platforms. Unfortunately, I think it will be a while before MS ever supports the CLR on other platforms, but it may be a possibility. Sure, ROTOR came out on BSD, but it's only an "Acedemic" reference.
The article is slashdotted, so forgive me if this is mentioned... Do they define what "life" is for a mouse? I mean, you could probably keep all of its systems going, but it might be in a comatose state for example. Ie, maybe the drugs they pumped into it completley frag it's brain functions. I think the mouse should have a decent quality of life in addition to having a long one.:) What good would having a long life be if you were immobilized, could only eat chease and crap your cage for the rest of your days? (OK, thinking about it, this might not be so bad...)
Slashdot Mirror
Wow, what a sad day for the industry. I guess this shouldn't come as a big surprise since we've been hearing about his health for some time now.
I also know it's been said many times, but Steve Job was truly visionary. The last decade, and particularly since the iPad has been released, have been tremendous in terms of the amount of influence he has made (though that's been the case most of his career at Apple). Over the past few years, I slowly started picking up Apple technology. As a long term PC guy this was a tough thing to do and in hindsight, I wish I'd started earlier! I hope his legacy lives on. One can only wonder how the face of computing would have changed if he had another 10 years.
Here I am typing this on my first ever Macbook Pro. I haven't logged in for a few years here on /. but thought this story was worthy of a post. Way to go Steve, Rest in Peace!
Didn't you read some of the articles about overriding ASP.Net JavaScript generation so it would be cross-browser (i.e., some of the JavaScript that ASP.Net is IE-specific, I think primarily regarding MS additions to the DOM).
Yeah, ASP.NET today generates simple javascript stuff for validating drop downs without doing post backs and that is about the extent of it. AJAX is more geared toward "more advanced" stuff, like loading a drop down based on a value that you pick in another drop down. In that case, AJAX uses an xmlhttp object to connect to a web service, grab the result, and update a control on the screen w/o having to post the page back- which is traditionally done on the server with ASP.NET.
For what it's worth, Live.com (and Start.com before it) uses Atlas. Building Gadgets for Live.com/Start.com is a good way to get your feet wet with Atlas, though they could do a better job of providing documentation.
Cool, thanks for the links. I haven't played around enough with Atlas yet, but it definitely looks promising. It may be "good enough" to switch over from the web service behavior we've been using (w/ our own custom client side functions).
It's nice to see that the "rest of the world" is finally seeing the importance of moving to decent web based user interfaces. However, the concept of AJAX has been around for quite some time. I was using a technology called "Remote Scripting" back in the late 90's that allowed you to hit server side pages via a "proxy" java applet, and then update your page however you wanted with javascript. Granted, it was pretty ugly code, but it made for a heck of a UI. No more annoying "flickering" on the web page, as the users used to call it.
.NET platform that Microsoft is making called "Atlas". It builds on AJAX but allows a developer to write ASP.NET server controls that render AJAX-ish code. At least that's the concept, I believe. Will be nice to see how it pans out.
I was quite displeased when ASP.NET came out and really put everything on the postback paradigm. They tried to cobble together something called "smart navigation" which was basically loading the page in a hidden frame and then updating the changes. What a waste! Instead, I was using the web service behavior. Downside is it only works with IE.
Now there is something on the
Having said all that, I'm glad that the rest of the world is catching up. Gmail was a big step in the right direction showing people the kind of functionality that AJAX can offer (though I don't think it's using ajax, I could be wrong though). Web apps are definitely "where it's at". I think we will begin to see the next evolution of web applications with this technology.
Where abouts in Ohio? I'm in Northwest Ohio. There is wireless internet for rural areas- about 1 mbit, for about $50 a month.
I'm in an area where we have some competition for cable co's, though DSL is not offered "yet". I'm paying about $100 / mo for 4.0 mbit down / 384 Kb up along with HDTV and VOIP through a company called Buckeye Express. I used to have DSL through SBC at my old house that was about $20/mo. Not too bad.
You're right, I was thinking of Kari Wuhrer... :)
SAme here, sliders was an excellent series. I thought it had a ton of potential. I even remember one episode that had a matrix like theme where people were walking around with these VR goggles but living in an alternate reality. There were several episodes like that, that eventually ended up being used in later movies. The chick in it was really hot, too (don't remember her name). Maybe they will remake that one some day though the idea isn't as fresh as it once was.
Nothing to see here, move along... :)
How about Sir Charge... Sur Charge... :P
isn't calling employees "resources" part of the problem that leads to the acceptability of the lack of loyalty to staff shown by many short-sighted companies?
I think a lot of it depends on the company. At the company I *used* to work for, they threw that term around like you weren't a person, but equated you to a piece of machinery that cranked out code and it made you feel low. When I first started hearing the term at the company I am now at, I was worried because of my previous experience- but I noticed it is mostly used only when talking about projects. I think you get into trouble when you use it to describe a person, their training needs, their effectiveness, etc.
Even so, it really seems to be the language of business when it comes to management. It does have an impersonal feel to it, but I'm used to it now.
Is it really "technology bounceback" or a new term for "dotcom bubble reinflation" ??
Not that it would be a bad thing.
No doubt, a good reinflation would be a nice breath of fresh air for those of us still in IT. I personally think IT is currently undervalued in many cases and a reinflation is necessary to retain good IT workers. When the economy does bounce back, I think we will see a lot of turnover- ie, IT going to the companies that do offer the good benefits again.
I entered IT when the bubble was getting going (early 98) and have been in since. For the past two years, the benefits of being in IT have certainly decreased- lower raises (the days of 10% minimum raises are gone!), having to "coordinate" work with India, doing the work of three people, etc. I don't think our IT department budgeted for training this year- which is sad, considering training is required to do you job-- you basically need to get it outside work (I do this anyway...). We're also hiring less local talent (in fact we can only hire new resources in India, but can still replace resources locally as needed). Sometimes I am convinced corporations are punishing IT departments for many of the indiscretions committed in the golden days. The sad thing is, our IT department has always been conservative and didn't get into the hype of the dot-bomb. I think it's just that many corporate execs still seem to have a bad taste in their mouths.
I disagree, and I think that's perpetuated by a number of bad habits, bad practices and simple job protectionism coming into play. It's much easier to keep a job if I'm seen as the only "craftsman" who can maintain a system.
There is some truth to that. In an ideal world, it may be possible to build a system once that could do everything perfect. But given the speed and chaos at which business requirements, applications, and technology change it is unlikely that the "art" aspect of software development will change any time soon.
Correct,
:)
"Technology and development tools are usually the issue..." should read
"Technology and development tools are usually NOT the issue..."
In other words, developers are perfect.
Not
But.. they are usually not the biggest problem.
Great link- I used a lot of the Standish report for some masters work.
Time and maturity are important considerations, but I don't think software development is totally an "engineering science" that can be likened to traditional engineering (mechanical, civil, etc.) Primarily because software development is so "chaotic" in nature. The chaos is not due to the lack of maturity, but more because of the human element. Simply put- software does not have the same level of objectivity as a bridge or sewer system might have.
I find it interesting that "methodology" was the biggest risk driver for a project.
I think the true crux of the problem with software development lies in understanding requirements. A methodology will most definitely HELP find the requirements, but I don't think it's directly the biggest risk driver.
In my experience the biggest problem is getting the users engaged in the requirements gathering. This is the most critical piece- no matter what methdology you use (and they will come and go) you still need to make sure that you understand the requirements. In most business environments, software development tends to a discovery process. In some cases the users can visualize a system and what it should look like, in others they cannot and it just may take a lot longer time. In that case, expectations should be properly managed by the stakeholders. PM's come in to play and should explain what is likely to happen- requirements will change, development or design may take more time, etc. Investigate other options for requirements gathering and understand not all of it may be able to be done on paper.
I've found that most business applications work best when I have users who have had some level of experience with Information Systems, who are committed to walking through what the system should do, and have support from management to do so through the entire development cycle. Technology and development tools are usually the issue, especially if you have competent developers.
This is incorrect, DOM 3 Load and Save was finalised back in April, and it has been implemented by multiple browsers already. You still have to mollycoddle Internet Explorer of course, so you may not think that it's worth your while to implement the W3C approach, but that's your call.
Unfortunately, Internet Explorer is still the ruling king in corporations and the Internet. So yeah, I am going to implement it how IE does. Also, this spec is pretty far behind the times. IE has had this functionality for over 3 years.
I love how everyone in the Linux community expects MS to drop everything they are doing and adopt this new W3C standard because it's a STANDARD. Therefore it "must" be better than what MS has been doing. I love it! So what about all of us who have written code already because there was no W3C standard?? Should we all be good programmers and go back and change our code just because? Heh, not in the world I work in...
Anyway, IE hopefully will end up implementing the W3C spec eventually, but April 2004 in the world of corporations (at least those that make money over the Internet) it is still relatively new. In your environment maybe.. (I take it you are either at a University) but not mine.
I've been using the XmlHTTP stuff in IE for a while now, in the form of "Web Service Behaviors". MS makes it pretty easy to use, and gives you support for both synchronous and asynchronous web services calls from the browser. Pretty cool stuff.
Of course, being a good MS developer, one should always look into the issues you posted...
1. How secure is this? IOW, does it rely on anything at all other than JavaScript on the client side, or does it hook into the OS on some level? If it does, how well is it isolated from the more dangerous bits in the OS?
It relies on JAvascript and the Browser. The browser uses an activeX XmlHTTP object. This is used in the same process as the browser runs in.
The security hole that I know of is not going to be on the client. If anything there is a whole from client to server in the communication. If you are using HTTPS or a custom encryption to communicate it's probably not a big deal. The only other big deal is if you are using public web services and don't secure your WSDL. That in my mind is the biggest issue. The behavior needs to have a WSDL in order for it to set up a proxy. WSDL by nature means you can get a listing of all the methods and parameters that a web service uses. So.. don't put anything super secure on your web service that a browser is going to be talking directly to.
2. If it does require anything other than JS - even if it does only require JS - is it Windows only, or have our good friends at Microsoft realised why a goodly portion of the tech community is, ummm, hesitant to accept thier 'vision' of what computing should be?
If you do a little digging you'll see that remote web service calls from the browser are still a relatively "new" thing. There is no W3C standard as of yet. There are other browsers (Mozilla, etc.) that have a similar implementation. For now, it's just like everything else.. wait until a standard emerges and the next version of the browser (or service pack) will probably implement it along with some "extensions".
For non MS types, check out Mozillas verison.
He tried to use Paypal to sell it, or he sold it for only $20?? Apparently, he doesn't place a high value on MS's source code...
One thing to be aware of- IISLockdown, while very secure, also causes a pretty significant hit on scalability. If you are running a huge site then be careful if you install this tool. I'm not sure what the impact on scalability is for the proposed fix just yet.. I'm guessing it's probably not as much overhead though.
Actually, that's a good idea, but the actual problem occurs before your application code runs. Since that is the case you need to code an event sink that is stored in the global.asx file, which is (or can be) a part of every .NET application. It's really easy to fix. I already patched a few of our sites. Anyone using code-behind will have to recompile to make the fix, other wise you can dump it right in the asx file and it will compile behind the scenes. I'll post more info in a JE soon.
In my experience, this is a difficult question to answer. There are many factors that you should consider in making a decision to use all stored procedures or not.
First, every business has different needs. Every software development group is also different in what they can or cannot provide. There are camps on both sides- many people in the database discipline will say "put everything in the database" while hard code developers will sometimes opt for queries in code.
Some considerations:
1) Consider the needs of your application. Is there a good chance your application will need to talk to another database platform or backend at some point in the future? This could be an argument for not using stored procedures. AS far as centralizing business logic goes, that can be done in just about any tier.
2) Where is your current bottleneck? How possible will it be to scale out your database server? If you are in a web farm scenario, your database server may be under significant load. Putting more logic on the database server can be a lot more expensive- it is typcially a lot cheaper to sacrifice performance on the backend for scalability. In other words, if you can keep your database server relatively load-free you can always add more web servers. I currently support a site that has over 2000 concurrent users at any given time, and currently our DB is the biggest bottleneck. It is a lot cheaper to cluster web servers than DB servers, since the DB is centralized and web servers can be duplicated easily.
3) Consider the experience of your staff and the culture of your IT department. If you have a lot of developers/dba's that are used to programming with stored procedures, and management is used to that paradigm, it may be difficult to change architectures without a compelling reason. "If it ain't broke don't fix it".
I'm sure there are other considerations, but those are probably the most three important ones I can think of right now.
1: Microsoft has been convicted of antitrust violations. Hence why .net can't be used by linux programmers. .NET on linux. There is also .GNU and some other projects. Rotor is only for "educational purposes" but it runs on OpenBSD.
.Net isn't unique
.NET developer I definitely have some comments on this one. One of the biggest reasons I "switched" to MS was because of the development tools available. Not only that, but also the support, and the willingness of the developer community (tons and tons of support- just do a google search), as well as Microsoft. There are MS dev leads that help support developers FREE of charge. Sure, the cost of the tool can be pricey, but you aren't just buying the tool. Also, I have never found a tool that has all the needed capabilities/performance/integrated environment of VS.NET in an open source project (for any language). Some open source Java tools come close, but they tend to be really slow and lacking one or two key features that I need to be productive.
What's stopping them? The go-mono project is quite active- I get at least 50 emails a day from linux programmers that are using
2: Blaster.
The most popular platform, ran by the most people in the world, etc. is bound to have security holes that get exploited. Unfortunately when 95% of the people out there don't know how to patch, these are blown way out of proportion. One company can only do so much to prevent the problems- anything else and you get complainers (see point #4).
Many linux groups are still nitpicky crazy people who instead of agreeing and copromising, they bicker. Even more are lazy, or greedy, or just plain stupid.
I've presented at LUG's and I would somewhat agree with this point. There are some people that are just interested in getting things work, but many of them are hecklers, complainers, etc. It's just the sub culture. I used to be "on the other side of the fence" and I know the mindset. Once I graduated college and started working with business, my perspective changed quite a bit. People are drawn to anger/hate/etc. and unfortunately leaders in the linux community help foster this so it continues to pervade.
4: Open source people see Microsoft's code signing as a way to enact DRM, which is a polite way of saying they want total world domination. Many linux guru's like the idea of code signing, they just don't like Microsoft and they have good reasons.
Exactly. MS starts implementing security to eliminate things that happen in #2, and now the complaints start rolling in. No matter what MS does there will always be naysayers. They will never be satisfied.
5: Linux, netware, and other operating systems are still used for servers more often than Microsoft's software. MS's software is only used on desktops because everyone knows it. I'v used KDE on suse 8.1, it works well for anyone accept power users and I see no reason for ma n' pa to spend $300 on a new copy of winxp so they can check their e-mail.
In most companies that I have worked in or with, Linux tends to be used primarily for non-critical systems. Solaris is used on any other *nix based system for critical things (eg. production oracle databases), and the hardware cost is astronomical in comparison. We are converting to Win2K servers. The license cost for a business is not what a consumer would pay, in fact it is significantly less (ex-$100 instead of $300 for XP). Most new PC's that companies order (ie, dell) come with WinXP anyway.
6: Coding tools for linux exist that are open source and that work well. Not everyone is coding in C.
Ok, as a
7: Linux is known for it's efficiency. On a server, efficiency > ease of use. Ms's software was designed for idiots,
I don't think it was designed for "idiots" but I agree that there is definitely a level of abstraction that MS unnecessarily gives the sys admin that ca
It looks like one of the rocks is pyramid shaped. Look at the bottom right quadrant of the pic, it's one of the bigger rocks.
.NET is a 10-year hedge against that. Thanks to .NET, MS has the ability to ditch Windows in the future. As Windows fades, MS can be assured that its other cash cows - MS Office, the backend products, etc are still viable and dont need rapid porting to a new platform....At that point - 5 years, 10 years, etc - in the future MS will have successfully allowed themselves to be #1 regardless of hardware vendor, architecture, operating system, and even written language!
.NET, I think you are right on the money. I've spoken with many technology "evangelists" (both Microsoft and non-microsoft) and here is what they see:
.NET CLR is going to be come the next operating system. Windows will run on top of the CLR. Similiar to how we went from DOS to running Windows to Windows running DOS (when necessary).
.NET becoming the base OS is evident if you know about "Longhorn", the next version of windows. The entire win32 API is going away and being repalced with the .NET framework (which will certainly be extended in it's present state to cover everything).
.NET. It's coming one way or the other. Projects like MONO are helping it exist on other platforms. Unfortunately, I think it will be a while before MS ever supports the CLR on other platforms, but it may be a possibility. Sure, ROTOR came out on BSD, but it's only an "Acedemic" reference.
From what I understand about the future direction of
1)
2) The move towards
What this means to me personally- I can't go wrong getting into
The article is slashdotted, so forgive me if this is mentioned... Do they define what "life" is for a mouse? I mean, you could probably keep all of its systems going, but it might be in a comatose state for example. Ie, maybe the drugs they pumped into it completley frag it's brain functions. I think the mouse should have a decent quality of life in addition to having a long one. :) What good would having a long life be if you were immobilized, could only eat chease and crap your cage for the rest of your days? (OK, thinking about it, this might not be so bad...)