Expecting More From Development Companies

There are few things I hate more than poorly written code examples that masquerade as useful tutorials/lessons/guides. Every day, readers of these “helpful” guides have no choice but to turn to the ASP.NET forums and Newsgroups seeking help. With a new blog sprouting up every second, I’d be a fool to launch a jihad against the mass-ignorance people seem intent on spewing; but damnit, why can’t large development companies get it right?

Of late I’ve had my sights set on Macromedia and their craptastically written .NET material. most of the .NET code you’ll find on Macromedia’s site is hugely insecure, impossible to maintain and likely to run slow as hell. Some of the material I’ll reference hereafter is written by independent authors that submit their work to Macromedia, but since they all show up on macromedia.com (some of them even featured), it’s squarely Macromedia’s responsibility.

Let’s look at this example on how to modify the CommandText of a DataSet:

CommandText='<%# ((Request.QueryString[“sortOn”] == null || Request.QueryString[“sortOn”] == “” || Request.QueryString[“sortDir”] == null || Request.QueryString[“sortDir”] == “”) ? “SELECT EmployeeID, LastName, FirstName, HireDate, Address, City, Region, PostalCode, Country, HomePhone FROM dbo.Employees ORDER BY LastName ASC” : “SELECT EmployeeID, LastName, FirstName, HireDate, Address, City, Region, PostalCode, Country, HomePhone FROM dbo.Employees ORDER BY ” + Request.QueryString[“sortOn”] + ” ” + Request.QueryString[“sortDir”]) %>

There’s actually a note below the code that says “Note that the above code must be on a single line; it cannot be broken into shorter segments over multiple lines.” This “single line” is (a) impossible to maintain (b) open to huge SQL injections (c) a slap in the face of N-Tier and OO design.

There are some examples that aren’t as bad, but still grate me. For example, this general tutorial on how to connect flash to .NET has this little gem in it:

void Page_Load( Object sender, EventArgs e)
{
 string queryString ;
 OleDbConnection connection;
 connection = new OleDbConnection( @“Provider=Microsoft.Jet.OleDb.4.0; Data Source=Server.MapPath( “Northwind.mdb” );   
 connection.Open();
   
 OleDbDataAdapter adapter = new OleDbDataAdapter( queryString, connection );
 DataSet dbData = new DataSet();
   
 adapter.Fill( dbData, “Results” );
 connection.Close();
}


To credit the author, he at least points out that “it’s a good idea to place the database in a private directory that is inaccessible from the web” and makes a small reference to Server.MapPath, but does any one actually think a database path should be coming in from the query string, un-validated?! What irritates me more is the lack of try/finally or using – simply because too many examples exhibit the same lazy oversight. Don’t give me any of that editorial crap for online resources either – 99% of the authors that write tutorials like this write code the same way. if (adapter is IDisposable) Console.WriteLine(“DISPOSE ME!”);

My disgust with Macromedia’s lack of groking .NET all began when I tried to familiarize myself with Flash Remoting (the binary protocol used for Flash to communicate with the server-side code). Page 6 of the PDF is a pretty big offender. Although the two examples above are pretty bad, the code written by Macromedia itself is even worse. Here’s an example of what I mean:

protected System.Data.OleDb.OleDbConnection sqlConnection;

public DataTable getProductsByCategory(int catId)
{
   string sql = “SELECT productId, name, description,
   categoryId, image, price FROM Product WHERE categoryId =
” + catId;
   GetConnection();
   OleDbDataAdapter da = new OleDbDataAdapter(sql, sqlConnection);
   DataSet ds = new DataSet();
   da.Fill(ds, “Products“);
   return ds.Tables[“Products”];
}
private void GetConnection()
{
   String source1 = “Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\\Inetpub\\wwwroot\\flashremoting\\samples\\db\\sports2000.mdb;“;
   // get a connection using the connect info that works on this SDK platform
   sqlConnection = new OleDbConnection(source1);
   try
   {
      sqlConnection = new OleDbConnection(source1);
   }
   catch(Exception)
   {
   }
}

To be efficient, I’ll use a list:

  •  Import a namespace but don’t use it (System.Data.OleDb is imported)
  •  Protected fields
  •  Hard coded connection string
  •  Less than meaningful variable names (“source1″, “sqlConnection” for OleDbConnection object)
  •  Perfect example of how to never swallow exceptions
  •  Not using command parameters
  •  Creating a dataset just to return a datatable
  •  Resources never released

Maybe it’s just me, but to add insult to injury, the comment “get a connection using the connect info that works on this SDK platform” doesn’t even seem to be written in English!

After seeing that code, it didn’t surprise me to see Macromedia’s actual .NET products lacking as well. They use an HttpModule where an HttpHandler would be far better suited. To get Flash remoting working, you need a physical page called FlashGateway.aspx. This page is empty and has no associated codebehind. Rather, the HttpModule checks to see if that page was hit to do it’s thing. It’s inefficient and screams of not understanding modules and handlers.

If a company writes documentation that features highly insecure code, what expectations should we have from the products it delivers? If their documentation results in hard-to-maintain code, how stable do we think their offerings will be? Macromedia’s development center obviously needs to step it up a notch and bring in some technical editors who know what they are doing.

This entry was posted in Grab a coffee before reading. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

14 Responses to Expecting More From Development Companies

  1. Thorsten says:

    @Karl

    I found your site 2 days ago. Nice site I must say. In times where code development is going worse a site like yours is a good place to stay a while every day.

    Among others I’m working with Flash (can i say this or must i say hacked with Flash?) since a couple of years and i can say you are right! people who deliver such documentations are writing such code. You must have a look at the mx ActionScript API!. And sadly I must say it’s the best documentation they ever had. =)

    In my opinion the reason for this is the market:

    Most of the developers, lets say 80% are happy when the viewable results are on screen. Regardless of which terrible sh** of code had done the work. -> “Exceptions are annoying. Let’s swallow them!! ” ; )

    But these developers (and chef developers) require such documentations.

    Sorry for my poor english. Thanks for this site!.. And never swallow exceptions!! =) =)

  2. [SteelValor] says:

    @foobar

    omg YES!! All mm docs suck to the point of no return

  3. foobar says:

    This is par for the course for MM. Their ColdFusion documentation was equally as bad (if not worse, sometimes).

    I have to seriously wonder if they know what the hell they’re doing over.

  4. Gregor Suttie says:

    I reckon these are valid points – I went out and bought the patterns and practices book for Improving .Net Application Performance and Scalability and these books should A) be pretty cheap and b) read by way more people as the code shows you a good way to do stuff and I wish most of the articles on MSDN followed the heres how to do it way and also have a here’s how it should be done properly way.

    More patterns and practices articles/book updates required for developers would be nice.

  5. Erik Lane says:

    Great post. On a side project, I am working with guys that live in Dreamweaver. When they need code samples where to they go? Yep, they go to Macromedia’s site and I know understand where their less than good code is coming from. We try and talk about it but they don’t get it and just keep on using stuff just like these examples.

  6. jpalermo says:

    I agree with most of this post. Obvious things like embedding connection string details IN the codebehind of a page. Those things are clearly newbie mistakes and should never make it to production code. These mistakes should never be in documentation. A completely reasonable alternative would be a short comment to describe where the connection string is coming from. For instance, in code that demonstrated how to execute a SqlCommand objects:

    string connectionString = //retrieve connection string from configuration
    SqlComma. . . . .

    and the example could continue.

    It need not be complete. In fact, I would prefer this approach since it would not work upon copy and paste. The programmer would fill in the obvious holes (getting an actual connection string).

  7. karl says:

    John:

    The links are in the article (the stylesheet is a light gray that can be hard to see):

    http://www.macromedia.com/devnet/flashremoting/articles/ado_connect_03.html

    http://www.macromedia.com/devnet/flashremoting/articles/ado_connect_03.html

    and the pdf one which isn’t linked (page 6)

    http://www.macromedia.com/software/flashremoting/downloads/sampleapp/files/flash_remoting_for_net.pdf

    Kent:

    I _love_ that example :)  I do have a follow up post in my mind with respect to 1 or 2 things I’ve seen on MSDN :)

    Eric:

    Sorry, I’ll get to the Flash stuff eventually, but you can check out http://amfnet.openmymind.net

  8. Kent Sharkey says:

    When I first arrived at “that place”, they were in the midst of a security scrub of the articles. It was frightening just how many articles hit databases with sa/ or were doing SELECT * queries.

    A lot of these sites suffer from a “more is better” mentality where they accept just about any content, with limited or missing technical checks. Site managers are typically not technical, and if the higher-ups have said, “We need content on “, they will throw anything on.

    On the complete/partial example discussion, I give you:
    http://msdn2.microsoft.com/en-us/library/system.drawing.color.burlywood(VS.80).aspx

    ‘sample of usage
    Dim value As Color

    value = Color.BurlyWood

  9. johnwood says:

    Do you have links to any of the above published samples? I’d be interested to look at them in context…

  10. karl says:

    Eric, I agree that samples need not be perfect. But I do think there should be a standard level of quality, and the Macromedia material falls short of that (by a lot).

    A sample that’s too perfect might be too implicit to understand (what the hell is that call to GetConfig() doing and why does it need to be passed to the SqlConnection’s constructor).

    One concern I had with the Macromedia stuff is I think (and I could totally be wrong) that there’ll be a high percentage of copy/pasting. This is material focused towards developers not primiarily focused on .NET (or similar languages). They don’t know that it’s wrong/incomplete. They want to get their flash app working and taking the sample to modify the connection string and select statement might be all the work they’ll put into it. Why should they do anymore, this does come from Macromedia after all. This is largely what you said in your last paragraph.

  11. Eric M says:

    One more thing, I’d be curious to learn more about how your are interfacing Flash with a .NET backend. So, consider my vote cast for topics of future blog posts.

  12. Eric M says:

    I think you are making two points here; one I agree with and one I don’t. Regarding your point that major companies are releasing products that are firmly grounded on platform ignorance and bad code, I agree. These are things that should not be allowed from any professional organization. Fortunately, I think the market weeds out poor products, so this issue often takes care of itself.

    Regarding your second issue that code samples should be written so they are secure, performant, and in any other way optimal, I disagree. The purpose of a code sample is to illustrate the particular usage of an idiom, technology, or syntax. I think they should be kept as spare as possible. I don’t want a large example that incorporates SQL injection attack prevention, proper use of configuration settings, and structured exception handling just to show me how to open a DataSet. Just show me how to open a DataSet and I can figure out the rest. However, you are right that the code samples above are terrible, because they are neither spare nor complete. They hit some ambiguous middle-point that serves no audience well.

    There is (at least) one hole and caveat in my disagreement. The hole is that code samples are how many people, especially people without formal training in computer science, learn a language and how to program, so it’s a valid point that we many want code samples to be excellent for their benefit. Constantly seeing good code reinforces good habits for those that are well trained and have years of experience. The caveat is that for samples illustrating how to program well or that with other examples form an entire application, then complete examples are necessary.

  13. ewise says:

    The real question is will this get better or worse under Adobe’s watch?