Dave Burke - Freelance .NET Developer specializing in Online Communities

Character parsing code snippet for kicks - updated

I inherited an ASP.NET app that I updated today.  One update was changing a SQL varchar field stored as numbers to letters, as in “1,2,3” to “A,B,C.”  (I'm saying its inherited because I probably wouldn't have stored comma-separated values in a single field had I designed the app.)

As numbers, the following worked fine: “...where code in (1,5,7).“

string sql = "SELECT * FROM table WHERE code IN (" + dr["code"] + ")";

But as letters it spit out an Invalid column name 'G' exception.  I needed to convert the “A,B,C“ string to 'A','B','C'.

This solution isn't clever, and as usual I would bet I get recommendations on how to improve it.  I'm posting it only because it was a 10 minute (at most) coding fix which in the not too distant past would have taken me a lot longer to do.  I can only attribute the decreased coding time to .NET, the economy of the C# syntax, and I'm a lucky cus who gets to write a lot of code.

string sql = "SELECT * FROM table WHERE code IN (" + GetCode(dr["code"].ToString()) + ")";

private string GetCode(string actions)
{
  // actions string = “A, B, C“
 string s = actions.Replace(" ","");
 string m = "";
 string[] arraychars = s.Split(",".ToCharArray());
 for (int i = 0 ; i < arraychars.Length ; i++)
 {
  if (i > 0)
   m += ",'" + arraychars[i].ToString() + "'";
  else
   m += "'" + arraychars[i].ToString() + "'";
 }
 return m;  // returns 'A','B','C'
}
 

[UPDATE]  I knew I'd get improvement suggestions on this.  Now instead of being happy about a 10 minute code fix, I SHOULD have been happy about a 90 second fix!  The updated function now consists of a single line.  Excellent, Jerry!

private string GetActionChars(string actions)
{
 return "'" + String.Join("', '", actions.Replace(" ", "").Split(',')) + "'";
}

Coding at High Res just like the young bucs

I remember working with younger guys than me (before I began working out of my home office in 2000) and looking at their screens set at some ungodly high resolution: 1280 x 1024, 1600 x 1024, etcetera extreme.  I wondered how in the heck they could look at those tiny characters all day long.  I had to enlarge the dots to 1024 x 768 several years back.  Then I had to get Varilux glasses at over $500 a pop and its been all downhill since.

But I bought a new 19“ NEC Flatscreen FE990 monitor recently for my my new Dell running W2K3 Server from CDW (for $249) and I set it to my comfie 1024 x 768 setting.  Then I noticed the hue flickering occasionally which bugged me.  The last monitor I bought (a MAG) had similar sensitivities which were resolved by changing the resolution.

So I upped the res on my new NEW to 1280 x 1024 and boy do I feel youthful!  There is now a ton of C# code on the screen and I can read every darn character.  I attribute it to this flatscreen technology.  Its really incredibly sharp.

Forcing myself from the keyboard and onto the slopes

I live and work as a fulltime teleworker in Burlington, Vermont with no timeclock to punch, yet I have to force myself to get out of my blind-drawn office and hit the slopes.  The nerd in me is completely happy to just code for the day rather than grabbing my gear and heading to Sugarbush, Bolton Valley, Smuggler's Notch, or Stowe for a few hours.  But darn it, day #2 of beautiful blue skies made me get off my butt and get out there, today, to Smuggler's Notch.  I made up the coding time tonight.  If skies are blue tomorrow, I might have to do it again.

The blurred line between server administration and developer responsbilities

My previous post about getting smtp services to work brought up an issue that we as developers often encounter:  resolving server issues which may or may not have to do with a server's configuration and the blurred line between a server administrator's job and a developer's job.

I've publically boasted about the great System Admin (and Network Admin Support stud) I get to work with.  When SMTP services did not work today, I exhausted every possible code-level fix along with investigating the MMC IIS SMTP setup.  Then I asked my SysAdmin to try the STMP test web page I provided in conjunction with inspecting both the server SMTP setup and any firewall port settings on the network to make sure everything is working on his end.  He always does this as a top priority, tests the web email page, and sometimes, like today, he'll say he checked everything and is still getting the error.  Then its back in my court to move forward on the resolution.  And he never, never says that something in my app must screwed up, which is usually the first thing System Admins say to developers.

My System Admin sets up the server, which includes SMTP; he's the owner.  If I make any changes, no matter how seemingly insignificant, I make sure he knows about them.  Tonight, I added a 127.0.01 to the accepted SMTP connection list because it was required in using the SmtpMail.SmtpServer = “127.0.0.1“  Hell, he's fine with that.  Its not an issue because of a long track record of good communications, mutual respect, and our sharing security best practices as a top priority.

I've always felt that developers have to be part network/system administrators.  No developer can write an application, let along an enterprise application, unless they understand how things work behind the scenes.  I feel strongly that developers become much better developers when they have their own network for which they are solely responsible:  for installing and configuring the servers, IIS, Exchange, SharePoint, SMTP, managing Active Directory, managing SQL Server, whatever. 

So a blurred line between SysAdmin and developer responsibilities can be a good thing.

Why can't IIS SMTP services "just work???"

I swear.  On every Windows Server on every network, I encounter a different weird-ass SMTP issue.  I understand you have authentication, connection, relaying, and routing issues with SMTP that can involve more than the IIS server itself, but it baffles me why every smtp setup is a brand new mystery to solve.  Why can't IIS SMTP services “just work???“

I've setup SMTP on so many servers and today I get a new error I've never seen before:  “The "SendUsing" Configuration Value is Invalid.”

At least a new error made things interesting.  And in the SmtpMail.SmtpServer property is where the mystery always magnifies itself.  I always used to enter the name of the local Exchange server for this value, and SMTP email would work.  Then it stopped working one day, I forget when.  Then I entered SmtpMail.SmtpServer = “”, which made things work again.  But today I use that setting but get nailed with a 550 5.7.1 relay error on external addresses.

SO, HOW IT WORKS TODAY, ON THIS PARTICULAR SERVER, ON THIS PARTICULAR NETWORK, AT THIS PARTICULAR PHASE OF THE FRIGGEN' MOON, is SmtpMail.SmtpServer = “127.0.0.1”, making sure to add 127.0.0.1 as authorized to connect to the SMTP services, as in shown on the IIS SMTP config box below.

DevDays 04: I'll be there!

Okay, so there are no GIF tags like with the PDC 03 in LA (which I didn't attend), but I just registered online for DevDays in Boston.  I am looking forward to the Smart Client track.  I always hate driving out of Vermont into the Big City, but this will be worth it. 

When not to serialize for charity

Answer:  when the KISS principal is not applied first.

I spoke in my previous post how I wanted to improve a page inheritance approach on a charity ASP.NET coding project by employing XML Serialization from an XML config file, similar to .text skinning in Scott's 0.94.  It seemed a good idea last night at 2:00AM, as I was excited about the potential of learning more about XML Serialization.  But in the light of day I realize that the way to improve on my inheritance model was to simplify my config file and base classes, not by adding a layer of XML Serialization complexity where it is not needed.  Someday that will be a “layer of XML Serialization simplicity” as I will continue looking for opportunities (mostly in those after-hours, non-billable sessions) to use serialization and use it often.  I think its a great feature of the .NET framework!

Barebones Page Inheritance, Charity projects, .text, and serialization

I've relaunched an after-hours asp.net charity project that I thought I dropped for good some months back.  But I really missed the whole experience of charity .NET coding, and now that I'm back in that groove I am convinced that everyone needs to have an after-hours charity project going.  There are several benefits to doing charity .NET work, but one particular benefit for me is the time I am able to spend getting my head wrapped around issues I don't have time to focus on during working hours. 

I wanted to employ a barebones page inheritance model, for instance, using a Basecontrol, a PageTemplate Control with Placeholders, and a control.config file with miscellaneous info and control loading info called from BasePages.  The beauty is writing inherited .ASPX pages containing a single line denoting the location of the inherited class and being able to focus on the controls which do the work.

I am basing this model on ScottW's 0.94 release of .text since I had spent so much time studying it.  Scott was supporting Skinning in the 0.94 release, of course, but the principal is similar.  After getting my inheritance approach to work, I realized that I could do it better and smarter.  So with no billable clock tick-tocking, I took the time to peel another layer from ScottW's 0.94 skinning code to discover that what I now had to get a handle on if I wanted to really do this right was XML Serialization.  Sweet!   

DevTeach, DevTeach, DevTeach!

Julie Lerman posts a few reasons why DevTeach is such a great conference.  As an attendee of last year's conference, I say DOUBLE DITTO! 

http://www.thedatafarm.com/blog/PermaLink.aspx?guid=a9229e5c-75ad-4d8f-b400-809422010809

InfoPath Review

I was asked recently to check out the potential uses of InfoPath at our company, and was thankful I got the chance to do so last week.   I learned about InfoPath by developing a working prototype form containing data populated directly from both SQL and a Web Service, and which passed its data to a web service to add a record in a SQL table.

InfoPath is a cool tool in that it packages up XML data nice and tidy with its own schema, allowing the developer to do practically anything with that data he or she needs to do.  I am totally impressed with how InfoPath "thinks XML." 

My issue is with the user experience.  I thought InfoPath would be a wonderful transitioning experience for my users as we move from web-based apps to rich-client winform apps in the months ahead.  I read much about the "rich InfoPath experience" and wanted to see it in action.

But I quickly discovered that InfoPath is NOT a rich user experience.  InfoPath forms are web-forms masquerading as rich client forms.  They are even more stupid than web forms because you do not have managed code to rely on for flexible validation and user prompting.  And if you don't enter all required fields (those are the ones that InfoPath puts the ugly red lines under them), when you click submit the only message users receive is: "the form cannot be submitted because it contains errors."  You can change the submit response message, of course, but options are few.  As for individual field validation support, there are really good support dialogs to set these up.  That is, if you want to check for anything OTHER than a blank field.  Nothing I did in the validation support dialogs to prompt the user on tabbing or clicking past a required blank field had any effect.

Forget about simple tasks like selecting a default value in a dropdown list.  Neither VBScript nor JScript has a ddlist.FindByValue("1").Selected = true; statement :-).  And that's the rub.  Anything you might want to do code-wise must be done in VBScript or JScript.  Oooo, now that makes for a rich user experience!

I also made the mistake of trying to replicate an application of sorts with the InfoPath prototype form.  In doing so I was able to add an Office Toolbar to InfoPath (by manually typing it into the manifest.xsf file under the appropriate "view" schema area), which was actually pretty cool.  This toolbar button displayed a secondary form (defined in InfoPath as a "view.")   But then I went to my secondary form and added a "Submit" button.  D'oh!  Only one submit button per InfoPath form!  And those fields you added on the secondary form? They're part of a single DOM XML file passed to your web service or URL on submit.  Not exactly the behavior you might expect in a normal application consisting of “multiple forms.“

A week is not long enough to evaluate the full potential of InfoPath, certainly, but I think it was enough time for me to conclude that I cannot recommend our company prioritizes using InfoPath over current web and Office-based services.  My main arguments against using InfoPath is that it is not a rich UI as claimed and its architecture (from a .NET developer's perspective) is waaay lacking.   And while InfoPath is marketed as a tool that any administrative assistant can use to crank out forms and move XML throughout the enterprise, that is not a realistic appraisal of its use at all.   An administrative assistant may very well design the form, but a developer will be required to spend precious development time adding the hooks to move the data in and the code to move the data out of Office InfoPath forms, confirming the data types, specifying field names, and so on. 

Or maybe I just didn't "get it."  Hopefully I'll get some good input from developers who DO get InfoPath.