Archives

Archives / 2003 / December
  • NASDAQ cut out its free XML feed...bummer

    Oh well, I guess you get what you (don't) pay for.  It was too good to be true...NASDAQ used to have a publicly-accessible XML feed for stock quotes, and I've noticed it's been inaccessible for several days, and finally found a couple links from some PHP gentlemen who said the service has been cut off.

  • Digital hypocrisy: crossing the use/misuse continuum on the Web with ROBOTS.TXT

    I've always found the optional file you can save in a Web site, ROBOTS.TXT, while sound in purpose, extremely hypocritical and potentially lethal to a site's integrity. As a guy who’s been in technical marketing for more than a decade, it's always been interest of mine to see the practical use of tidbits of information towards giving a site maximum exposure. As a budding developer years ago, this was also one of my first forays into “security“.

    As a refresher, ROBOTS.TXT is a simple text file stored in the root directory of a Website, containing metadata, instructing search engine spiders which directories/subdirectories to avoid browsing so as not to include sensitive information in their indexes. A simple concept, but the fact that these files can be browsed by any idiot with a browser and Internet connection of any speed makes them dangerous.

    For more on ROBOTS.TXT, visit
    http://www.robotstxt.org/wc/robots.html

    It's literally like saying, "Hey, there are certain directories I have secretive content stashed in, and I don't want you to see them at all...and here they are."

    Need proof? Check these URLs out for some good examples how varying organizations in varying industries creatively use the file:

    http://www.intel.com/robots.txt
    http://msn.espn.go.com/robots.txt
    http://www.ford.com/robots.txt
    http://www.cisco.com/robots.txt 
    http://www.cnet.com/robots.txt 
    http://slashdot.org/robots.txt 

    In fact, if memory serves, I recall an engineer at Sun Microsystems several years back writing quite the scathing criticism about the use of ROBOTS.TXT on
    www.sun.com, seeing as how it gave hackers one less challenge to break their stuff (Sun apparently had a bunch of internal download sections, CGI scripts and administrative utilities located in directories they didn't want search engine spiders to find out about). By storing the directory names in ROBOTS.TXT, Sun was essentially giving people the direct URL(s) to their private information, which granted was password-protected, but still overcame arguably THE major hurdle of hacking a site - figuring out which directories contain the good stuff.

    As for me, I constantly use the META tag in pages I don't want spiders to see. That normally does the trick. Using ROBOTS.TXT improperly just invites users savvy enough to know it exists (as many of you now do, after reading this) to type in your site’s domain name, and appending “/robots.txt”.

    To be the file’s proponent, it does do an effective job of preventing spiders from indexing your stuff. And sure, this locks unwanted access out from I'd dare say 97% of the Web browsing community. It would only be Web developers trying to hack Web developers, and one would hope that there would be enough honor among thieves, as it were, or at least an appreciation for parity, that savvy people would not engage such pursuits.

    However, some organizations do use the file to their advantage, not implementing it as a security means, but more so as a way to not let redundant content or data that would otherwise clutter the Web even more be indexed.

    Check out:
    http://www.asp.net/robots.txt 
    http://www.google.com/robots.txt 

    And just in case you’re wondering, don’t even bother looking for the file
    on my site - it doesn’t exist. :)

  • Why even bother asking for permission to link to a site?

    OK...I'm a web guy in the TV/media biz, so I'm not exactly surrounded by a huge community of people who subscribe to the software developer’s way of life.  In other words, I get a lot of requests from people from all walks of life who think “you’ve got a great Inter-web,” try to email 90MB TIFFs embedded in Word documents, and constantly ask me where on the Internet they can find information on any topic, as if I’ve got Google’s entire search index stored mentally.  You get the picture.

  • SUGGESTION: formatting/color-coding changes for VS.NET

    I spoke to a Microsoft usability engineer recently who said there were discussions about possibly changing the color coding scheme employed by Visual Studio .NET.  While I'm totally happy with the current formatting convention used by the IDE (blue for language-specific keywords, green for comments, gray for in-line documentation, bolded purple for classes, etc.), I'd like to make the following suggestions:

  • SUGGESTION: allow control for CatalogWebParts via remote windows in ASP.NET 2.0

    I think it would be a nice touch if the Portal Framework could have functionality included wherein a developer woulnd't have to drop a CatalogWebPart on the same page as being worked on. For instance, the Framework could include a method or property that allowed child/popup windows control the changes and then upon submission, commit the changes back to the parent page.

  • I'd like to see an ASP.NET-specific extension to UML (and support in Visio wouldn’t hurt, either)

    Jim Conallen of Rational wrote the seminal book “Building Web Applications with UML”, in addition to penning numerous resources, available from IBM's site.  He describes the Web Application Extension for UML (WAE), which is a great, scaled down philosophy for laying out components, interfaces and page relationships/mapping – both cosmetic and functional - within the context of a web application. 

  • ASMX sample response message using serialized XML doesn't account for derived members

    I've noticed something in the sample response XML generated by an .ASMX file in ASP.NET 1.x (at the very least, in 1.0).  Specifically, when using serialization for custom XML, the Web service apparently does not take into account data members derived from a base class when reporting what a response message will look like.  Don't get me wrong, the final XML message itself is perfect, but I've found inaccuracies in the .ASMX  response message.
     
    For instance, here's an example I ran into when working on a statistic service for a local football league.  I used a base class "Player", containing only properties.  The classes "Offense", "Defense" and "Special Teams", all contain statistical information, and inherit from Player to get the shared properties Name, Position, JerseyNumber and Team:
     
    public class Player
    {
           private string _name;
            private string _position;
            private string _jerseyNumber;
            private string _team;
           
            public string Name
            {
                get { return this._name; }
                set { this._name = value; }
            }
           
            public string Position
            {
                get { return this._position; }
                set { this._position = value; }
            }
           
            public string JerseyNumber
            {
                get { return this._jerseyNumber; }
                set { this._jerseyNumber = value; }
            }
           
            public string Team
            {
                get { return this._team; }
                set { this._team = value; }
            }
    }
          
        [XmlRoot("OffensiveStats")]
        public class Offense : Player
        {
              // implementation...removed for brevity      
        }
       
        [XmlRoot("DefenseStats")]
        public class Defense : Player
        {
              // implementation...removed for brevity
        }  
       
        [XmlRoot("SpecialTeamsStats")]
        public class SpecialTeams : Player
        {
            public int Punts
            {
                get { return this._punts; }
                set { this._punts = value; }
            }
           
            public int PuntReturns
            {
                get { return this._puntReturns; }
                set { this._puntReturns = value; }
            }
           
            public int PuntReturnTDs
            {
                get { return this._puntReturnTDs; }
                set { this._puntReturnTDs = value; }
            }
           
            public int KickoffReturns
            {
                get { return this._kickoffReturns; }
                set { this._kickoffReturns = value; }
            }
           
            public int KickoffReturnTDs
            {
                get { return this._kickoffReturnTDs; }
                set { this._kickoffReturnTDs = value; }
            }
           
            // default class constructor...required here for serialization
            public SpecialTeams()
            {}
           
            // overloaded class constructor
            public SpecialTeams(string name,string position,string jerseynumber,string team,int punts,int puntReturns,int puntReturnTDs,int kickoffReturns,int kickoffReturnTDs)
            {
                base.Name = name;
                base.Position = position;
                base.JerseyNumber = jerseynumber;
                base.Team = team;
                this._punts = punts;
                this._puntReturns = puntReturns;
                this._puntReturnTDs = puntReturnTDs;
                this._kickoffReturns = kickoffReturns;
                this._kickoffReturnTDs = kickoffReturnTDs;
            }
        }
     
        [XmlRoot("Leaderboard")]
        public class Leaderboard
        {
            [XmlArray("Offense")]
            [XmlArrayItem("Player")]
            public Offense[] offensePlayers;
           
            [XmlArray("Defense")]
            [XmlArrayItem("Player")]
            public Defense[] defensePlayers;
           
            [XmlArray("SpecialTeams")]
            [XmlArrayItem("Player")]
            public SpecialTeams[] specialteamsPlayers;
        }
     
    As you can see, the Leaderboard class contains arrays of Offense, Defense and SpecialTeams objects to generate rosters of the statistical leaders in those respective categories, and it's this latter class that's returned by the Web service.  Pretty cut-and-dry stuff, and far from groundbreaking.  But here's where I noticed a gotcha: while the eventual XML generated contains all the fields and properties from the subclasses, as one would expect, the .ASMX file does not include the fields within the base class. 
     
    In my particular implementation, I'm reading values from a DB, which are read into the dataset and then passed as arguments to overloaded constructors of the Offense, Defense and Special Teams classes.
     
    However, this is the sample response the .ASMX file generates:
     
    <?xml version="1.0" encoding="utf-8"?>
    <Leaderboard xmlns="http://stats">
      <Offense>
        <Player>
          <TotalTDs>int</TotalTDs>
          <RushingAttempts>int</RushingAttempts>
          <RushingYardage>int</RushingYardage>
          <RushingTDs>int</RushingTDs>
          <PassingAttempts>int</PassingAttempts>
          <PassingYardage>int</PassingYardage>
          <PassingTDs>int</PassingTDs>
          <Receptions>int</Receptions>
          <ReceivingYardage>int</ReceivingYardage>
          <ReceivingTDs>int</ReceivingTDs>
        </Player>
        <Player>
          <TotalTDs>int</TotalTDs>
          <RushingAttempts>int</RushingAttempts>
          <RushingYardage>int</RushingYardage>
          <RushingTDs>int</RushingTDs>
          <PassingAttempts>int</PassingAttempts>
          <PassingYardage>int</PassingYardage>
          <PassingTDs>int</PassingTDs>
          <Receptions>int</Receptions>
          <ReceivingYardage>int</ReceivingYardage>
          <ReceivingTDs>int</ReceivingTDs>
        </Player>
      </Offense>
      <Defense>
        <Player>
          <Interceptions>int</Interceptions>
          <InterceptionTDs>int</InterceptionTDs>
          <FumbleRecoveryTDs>int</FumbleRecoveryTDs>
          <Tackles>int</Tackles>
          <Sacks>int</Sacks>
          <Safeties>int</Safeties>
        </Player>
        <Player>
          <Interceptions>int</Interceptions>
          <InterceptionTDs>int</InterceptionTDs>
          <FumbleRecoveryTDs>int</FumbleRecoveryTDs>
          <Tackles>int</Tackles>
          <Sacks>int</Sacks>
          <Safeties>int</Safeties>
        </Player>
      </Defense>
      <SpecialTeams>
        <Player>
          <Punts>int</Punts>
          <PuntReturns>int</PuntReturns>
          <PuntReturnTDs>int</PuntReturnTDs>
          <KickoffReturns>int</KickoffReturns>
          <KickoffReturnTDs>int</KickoffReturnTDs>
        </Player>
        <Player>
          <Punts>int</Punts>
          <PuntReturns>int</PuntReturns>
          <PuntReturnTDs>int</PuntReturnTDs>
          <KickoffReturns>int</KickoffReturns>
          <KickoffReturnTDs>int</KickoffReturnTDs>
        </Player>
      </SpecialTeams>
    </Leaderboard>

    Note that the fields inherent to each class are represented, but the inherited fields (Name, Position, JerseyNumber, and Team) aren't there.  This is consistent through the sample response content generated for requests made through SOAP, HTTP-GET and HTTP-POST.  However, everything comes out perfectly, as expected, when executing the method and examining the XML.  Certainly, a consumer of the Web service can see the true XML returned by invoking the method, but it makes for some unexpected surprises and misdirection when the true data to be returned isn't reported.

    If this was the result of ignorant on my part or a genuine flaw in the .NET Framework, I'd just like to know which.  Either way, it didn't produce the results I expected, although fortunately, it still worked perfectly in the final wash.  I researched this for awhile, and tried a few different approaches, and I thought I got it right.
     
    Anyone else run into this?

  • VS.NET *should* wrap all attributes with quotations by default

    I’ve got a comment/suggestion about the way VS.NET Whidbey handles the values for HTML attributes and declarative control properties. If the intent is to truly output XHTML 1.0, I was assuming that the IDE would naturally generate attributes and properties that would be surrounded by quotes (i.e., <a href=“adoc.html”>, <asp:Label id=“myLabel”/>).

    However, I’ve often found that when IntelliSense tries to autocomplete values in the way I’ve been used to since the Visual InterDev days (hitting “TAB” to autocomplete a statement, member or method), the quotes get left off and write out the above examples like this: (<a href=adoc.html>, <asp:Label id=myLabel/>).

    I’d like to suggest that these type of statement completions be set to wrapped in quotes automatically.  Is this just me or is this a known **bug**?

  • Suggestion: all IEWebControls should ship as part of ASP.NET 2.0

    I've got a quick suggestion I'm hoping Microsoft would consider: can the IEWebControls (TabStrip Control, et al.) ship as part of the standard package for ASP.NET 2.0? I think the TreeView is great, and it would be perfect if the controls that could be downloaded with 1.x came out-of-the-box with Whidbey.

  • Book Review: A First Look at ASP.NET v 2.0

    The scientist Louis Pasteur is famous for, amongst other things, saying, “chance favors the prepared mind.” With Whidbey on the horizon, Dave Sussman, Alex Homer and Rob Howard, are getting you prepared for battle, as you combat long, drawn-out development sessions and having to write thousands of lines of code. You’ll definitely want to pick up a copy of this book to properly arm yourself.

    Whether you’re an existing alpha tester or one of the many who is privy to a PDC copy of Whidbey, this is the definitive source you’ll want in your arsenal for the next evolution of ASP.NET. There’s code galore, and the concepts are explained easily and well, while still mixing in the specifics of how the next version of .NET will help you become a better web developer.

    The book’s hearty 470+ pages display a tone that is friendly and comforting, which is a plus when taking into consideration the literal piano of information about new features and enhancements that will be dropping on you. It seems to be best read by an experienced ASP.NET developer, familiar with concepts and terms inherent to Microsoft web development. One will quickly welcome the perspectives given on a variety of topics from caching to the new server controls, to the enhancements Version 2.0 of the .NET Framework delivers.

    The book does not completely marry the reader to the Whidbey version of Visual Studio .NET, rather presenting the code examples in an IDE-agnostic manner, so as to still appeal to the NotePad enthusiast in all of us. Still, the vast and massive improvements to VS.NET itself are well documented.

    All the book’s examples are presented in Visual Basic .NET, which isn’t so bad, as one of the key points of the title is that Whidbey’s new model minimizes the authoring of code itself, so you can concentrate more on working with encapsulated server controls and optimizing your web apps through intelligent configuration and management utilities.

    A very healthy chapter on Web Parts and Whidbey’s model for the portal framework is most appreciated, and the ease by which you’ll sift through the accompanying code just goes to prove how much better developing web-based applications will be once Whidbey arrives. Equally-thick chapters on new aspects of the feature set such as master pages, membership, and personalization, as well as great discussions of the improvements to the existing security, data controls, configuration and administration.

    The book also does a great job of keeping multi-platform application development in mind, constantly mentioning the capabilities of Whidbey to generate output for both the desktop-based and mobile browser.

    My personal favorite new feature of ASP.NET 2.0 is Web Parts and Personalization, and the book has a great deal of information on both. The book proves that not only has Microsoft listened to customers and thought way ahead in developing the next big thing, but the title’s authors themselves answer many questions you’d likely ask.

    If you’re wondering if this book (and Whidbey in general) is worth it – believe the hype. Get this book now. You’ll be very happy you did, and will be anxiously anticipating the release of Beta 1.

  • Book Review: ASP.NET 2.0 Revealed

    This book is much more demonstrative and visual than some of the other titles currently on the market, making it the ultimate complement for books like “A First Look at ASP.NET v 2.0”. Overall, the book’s tone is very educational but not intimidating, complex but not complicated, making for a very friendly atmosphere that makes it quite easy to read.

    The book tackles some of the more technical topics involved with developing and administering ASP.NET web sites, so it’s an effective tool in lightly previewing what’s coming on the horizon for us, as well as giving you the in-depth answers to allow you to start planning to solve problems and work more efficiently.

    In each of the title’s 13 hearty chapters, there’s great examples that accompany most, if not all of the concepts presented. So, you don’t get an empty, lost feeling after being drawn-into an idea – it’s succeeded with a relevant, working C# example.

    The book is definitely written for the web developer already primed with experience in ASP.NET 1.x, so familiarity with the concepts of Microsoft web development is a must. But assuming that, you’ll be very pleased.

    Specifically, there are several areas in this book I found to be outstanding. These include a fantastic introduction to generics, iterators, anonymous methods and other new features of both C# and Visual Basic .NET. Also, there’s a great description of using the ObjectDataSource control for binding business objects to data controls, and an equally nice discussion of the Site Counter API and keeping tabs on the user currently on one’s site. The book also has a good chunk of information about the improvements to working with dynamic imaging, and about the easy by which you can create and control client-side script.

    Additionally, there’s a great preview of the Whidbey version of Visual Studio .NET’s features specifically for web developers. Provides constant tips and comments about what features are likely to be changed by the Whidbey Beta.

    The sole bit of criticism I would have it that, the chapter on Web Parts chapter was interesting, but largely took from the documentation and samples you can find on MSDN and in the .NET Framework documentation.

    But outside of that, the positive far outweigh the negatives, and if you’re on the hunt for anything and everything you can get your hands on about the

  • IntelliSense for web.config files in Whidbey

    I bounced the topic of IntelliSense for web.config off the ASPAdvice general mailing list for Whidbey (aspnetv2@aspadvice.com), commenting about how I love the fact that syntax gets coloration treatment, as do all XML files (I haven't tried XSLT files yet).  However, as sweet as it is, it's a let down without IntelliSense support, which is a downer, seeing as most values in config files are emulation-based.

  • Working on Web Parts, C# 2.0 Generics...

    Well, it took me long enough, but I've gotten here.  I've been working on different ideas for Web Parts...trying to develop some sort of anonymous personalization, mainly.  Basically, I'd like to give my users the ability to check out my site and reconfigure the physical layout of the different content areas, WITHOUT having to signup for membership.