Bad news to all you AMD fans (yours truly included), Microsoft has announced that the upcoming Windows 2003, 64 bit edition will *not* have support for Opteron's 64 bit mode!
Bad move Microsoft. Your new mantra is supposed to be "competition is good", but this reeks of a side deal with Intel. Us, the users, want 64 bit power, but until competition helps lower costs, we can't afford it.
Ok, maybe 64 bit is supposed to be for big iron, but someone once said that 640K would be all the memory we'd ever need. What can we do to get you to change your mind MS?
Few five years olds have had as much impact as our little XML has these last few years. What started out as just structured storage as really changed into computer technology.
Now that Verizon has been ordered to rat out their users to the RIAA, Internet privacy is over...but maybe for the better. Sure I loved the high-flying days of song swapping, but where is the line between privacy and intrusion.
In the last few weeks a number of comparison between Java and .NET have been floating around. As much as I am interested in these comparisons on an intellectual level, I really don't care on a practical level. Do most day-to-day developers really care? Sure, the number of jobs out there for any particular skill set move with the tides so most of us care. But on a purely technological comparison, the differences is minimal.
These comparisons just help fuel the religious fervor between the Sun v. MS camps. I thought that today's world was more interopability and web services we could perhaps just put the differences aside and stop caring about which specific features are better or worse in each platform. Truth be known, most every project could be developed in either toolset with little change.
Last February Bill Gates announced that he was halting development until every project could be reviewed for security and make sure every developer knew how to write secure code. In fact, a pretty great book came out of the process. So did it work?
I've been in the market for a new laptop for the last few months. With the upcoming new laptop ideas coming out (Tablet PC's, Smart Displays, etc.), I decided to wait for the technology to catch up to my desires. Finally everything is out!
Back in ancient history (the mid '90's), I worked with Toshiba tablet systems running Windows 95 for a vertical market package. I loved the form factor and secretly wished for a touch display for my laptop for years now.
Ok, maybe this may be petty, but why do so many sites require that 'www' before the names? I have wasted lot sof time trying to navigate to sites by just their domain name, only to find out that I need the 'www'. What do I mean? Both of these should work:
But then why would some develop a site that doesn't work like that. For example (with apologies to Brent Rector):
I recently read about the reemergence of Code Generation on Chris Sells' News page. It seems that John Lam has been converted, but not by Chris. As some may know, I worked with Chris Sells while he lead the team that built DevelopMentor's Gen<X> so that I have been thinking about this code generation question quite a long time now.
When I first read the SOAP specification I could not decide whether it was meant to be a replacement for DCOM/RPC or whether it was a messaging protocol. I loved the fact that the ligua franca of SOAP was XML. But at the same time, Section 5 supported the RPC view of SOAP. Unfortunately this section seemed to just confuse the issue between the RPC world and the document/literal world.
In a great MSDN Article, Tim Ewald argues against support for Section 5 support. I guess I haven't been keeping up, but I am excited to hear that Section 5 support is now optional in SOAP 1.2 specification. Yeah...but will Section 5 really ever die?
I like to think I am open minded about technology. I have used a variety of database engines in the last seventeen years; xBase, Access, SQL Server, Sybase, Oracle, and DB2 to name a few. I like the direction Oracle 9i is taking and hope that Microsoft's SQL Server takes some of the same direction. But I think Oracle is missing a great opportunity.
I have been reviewing a bunch of code that utilizes ADO.NET's DataAdapters. This code has been some samples that are on the Internet, some questions directly to http://wildermuth.com and others from DevelopMentor's .NET Mailing Lists. One thing I have noticed is that much of that code is opening the database connection before using the DataAdapter to fill a DataSet.
This does work, but there seems to be some confusion about how this should work. In fact, under the covers all DataAdapters open and close the database if it has not already been done. This is because the DataAdapter knows when to open and close the connection to the database to minimize the length of time that the precious resource (the connection) is actually open. This is what the code looks like that I've been reviewing:
I just attended the second day of Chris Sells' and Tim Ewald's great Web Services DevCon East and had a great time. Yasser Shohoud gave a wonderful talk on "The Right Way to Build Web Services". He echoed something I have been thinking of for some time. Sure, I didn't want to learn how to write WSDL. At the same time I know that the WSDL that is generated by using the '?wsdl' syntax of ASP.NET's .asmx files does not let me design the interface first. I changed my mind and learned to write WSDL. WSDL really isn't too difficult to write. It is too bad that we cannot disable the ?wsdl syntax and just use a static WebService.WSDL URL to have our customer's get our WSDL files.
My natural inclination is still influenced by my days developing COM components in ATL. I want to define the interface up front like we did with IDL. In the early days of ATL, I had been doing MFC work and did not want to hand-code my own IDL either. You would think I would have learned by now that by starting with interface is the better development model. By writing our own WSDL we can define our interfaces (both the calling convention and the schema of the message) and run WSDL.exe to build a skeleton class for us to implement the service.
Why is everyone so down on using DataSets in .NET Web Services? Sure, I’ll admit that using DataSets directly as Web Service parameters are indeed a problem. But why throw the baby out with the bath water?
For the uninitiated, DataSets are a problem as Web Service parameters because XML that is automatically generated as the parameter is a DiffGram of the DataSet. Unfortunately DiffGrams are simply not interop-friendly. At the end of the day the obvious use of DataSets in .NET Web Services are simply a bad idea.
I was recently in a DevelopMentor course when I ran into a very interesting observation. The XmlSerializer serializes any class that dervies from XmlNode (including XmlDocument, XmlElement, et al) as plain XML. Previous to RTM of the .NET framework, these classes were serialized like any other class (all public properties and fields were serialized). To our amazement (Dan Sullivan and mine), we realized that the XML classes serialized perfectly when run through the XmlSerializer class.
Ok, neato but why do I care? As a developer using ADO.NET, I realized that by utilizing the XmlDataDocument and specifying an XSD for my DataSet, I could have my Web Services return an XML as specified by the XSD without ever doing transformation of the data going out of the Web Service.
When the XML revolution happened, I was surprised how quickly developers jumped on to the coming tide. I have to admit, the first time I saw XML, I believed it was nothing more than just structured storage. That is the magic of it, isn't it. It is just structured storage, but a structured storage format that is universally understood.
So I think we have reached a crossroads with XML. The toolsets have made it so easy to use that I think there is a bit of overuse of XML. Afterall, XML is just structured storage, but it is inefficient structured storage. When we use XML we are giving up performance and efficiency for the portability of the format and the richness of tools to work with it (the tangential technologies of XPath, XSLT, SOAP, etc.). I like to think of XML as a way to enable enterprises to speak with each other in a common way. With that in mind, are we not (as developers) overusing XML? I think so.
For those who do not know yet, the XML integration with the DataSet is very powerful. Most of the integration is about filling and getting XML from your DataSet. But the XmlDataDocument is really cool. Simply by assigning the DataSet to the XmlDataDocument, you can work with the DataSet data either relationally (through the DataSet) or hierarchically (through the XmlDocument). So, next time you need to transform the DataSet data or just run an XPath query, assign your DataSet to an XmlDataDocument and watch the magic begin...
Too many times when I am asked to look at old ADO code, the recordsets are created with a slower cursor than they actually need. This especially prevalent in ASP code. In most every piece of ASP code, the job of the page is to report existing data. In that case you should always us a adOpenForwardOnly cursor. Remember, if you are only reading the data, the other cursor types are using extra database resources and will cause extra round trips to the database. If you are using other cursors just to enable being able to go backwards in the recordset, it is almost always better to use the adOpenForwardOnly cursor and cache the data locally to allow for reverse transversal.
Am I the only that abhors this dreadful API? I understand the usefulness of using Parameters.Refresh() during development. The problem lies in the fact that is it just too easy to leave the code in place. Including an extra network round-trip in every call to this call is simply a waste of time. Now I know that you are an intelligent programmer that never wouldn never leave that code in place, I am talking about all the other programmers that would. Most databases (ignoring Access) allows you to query the database for the information about parameters. Since the database supports, why does ADO have to? I don't think it does.
Anyone else remember the promised "In-Memory Database" (IMDB) that was to be part of COM+ some years back? Well, Microsoft has finally delivered a first version of it in ADO.NET's DataSet class.
For those who haven't take a look at ADO.NET yet, don't make the mistake of assuming the DataSet is a replacement of the Recordset from ADO. DataSets contain one or more tables. Tables can be setup with relationships, keys, constraints, etc. Though a real SQL engine does not exist (yet), DataSets do allow you to re-create some of your databases in memory. If you are attempting to scale your database servers, please take a look at this very cool technology!
Ok, this pet peeve is a biggie. Over and over I have seen database schemas that simply defined the table structures and some stored procedures. Most modern database systems support advanced features for maintaining database integrity.
If you are going to go through the trouble to define a database schema, please finish the job. The database will help you do your job if you simply define Relationships, Constraints and Triggers. There are good tools for helping you do this. I really like ERwin or Visio for designing databases.
The most common error I see in badly scalable database code is reckless use of the connection object. For all multi-user database programming (which accounts for most of the work these days), database connections are a limited resource. Don't let it be your code that is hanging on to his connection way after you are finished with it. I am *not* saying that all work can be done disconnected. I am simply asking you to keep in mind that Connections are precious things. Try to do these two things:
|Implementing and Securing an API with ASP.NET Core (new)|
|Building a Web App with ASP.NET Core, MVC6, EF Core and AngularJS|
|Building a Web App with ASP.NET5, MVC6, EF7, and AngularJS (Retired)|
|Best Practices in ASP.NET: Entities, Validation, and View Models|
|Front-End Web Development Quick Start|
|Lessons from Real World .NET Code Reviews|
|Node.js for .NET Developers|
|Application Name||WilderBlog||Environment Name||Production|
|Application Ver||126.96.36.199||Runtime Framework||.NETCoreApp,Version=v1.1|
|App Path||D:\home\site\wwwroot||Runtime Version||.NET Core 4.6.24628.01|
|Operating System||Microsoft Windows 6.2.9200||Runtime Arch||X86|