Back in July we had Chad Miller visit oPASS to do a presentation on Powershell. It was well received and kudos to Chad for a nice presentation and taking the time to drive up from Tampa. Going in to the presentation I would say my view of Powershell was interesting, but over hyped, but then again, I’m typically not a bleeding edge adopter of technology either.

Chad made some interesting remarks during the presentation (and apologies if I put words in his mouth by accident):

• SQL Server people “get” scripting faster than others do in his experience. He attributes that to the fact that so much of we do are scripts already. Syntax is different, usefulness of the concept is already engrained
• Believed that Powershell was powerful because it took relatively few lines of code to do complex tasks
• Ease of discovery of properties/methods makes it easier to learn
• He’s looking forward to the day when presentations are less about the basics and more about solving real problems with it

The first one sounds plausible. The second – I think – is over stated. I’m sure there is a limit, but verbosity of code has never struck me as a major impediment to getting things done. Of course, that assumes more than passing comfort with the syntax. I’m probably also biased, as many C# people consider VB.Net to be verbose, but I find VB.Net to be reasonable. In both cases it’s the difference between code you really write and pre-packaged/reusable code that impacts productivity. On the third one I agree about 50% – PS does make it easy to discover, but so does the Visual Studiio IDE, either via the object browser or via the immediate window. Calling it 50% is probably unfair, because I think easy of discovery is critical to learning any new product. The last point was really great, until we build that shared knowledge it’s hard for anyone to move into deeper areas. Interesting to see how (if) this moves forward in the next couple years.

I’ve done my fair of scripting and batch files over the years, ranging from almost vanilla batch files to more advanced ones using things like PC Magazine Batchman (best link I could find), VBScript, and just a small amount of PS work so far. Scripting is a useful technique, but once I moved into “real” programming environments I found that going back was hard. Even VBScript scripts I’d write in VB6 for the intellisense, debugging, etc, and then as a final step make it a true VBScript file. I’d say in many ways that a very nice IDE trumps all, for learning and pure efficiency. The Powershell IDE seems  like a useful step in that direction, but note quite all the way there.

Some of us will need PS at work, others may never need it. As SQL professionals I think we need to know the basics; what is Powershell, how to load and run a script, the basics of variables and comments. After that you make the decision about where to spend your very limited professional development time – do you learn more PS, Analysis Services, or even something else? No wrong answer.

For those that really enjoy Powershell, I’d suggest taking one more step and trying a “real” language, something that has a first class IDE, supports all the concepts that go into programs today. A good way to do this is with SMO (SQL Management Objects) to build a first class UI around some solution you need. You can call SMO from PS of course, but if you want something really sophisticated, use Visual Studio or similar. Make sure you learn how to use source control either way, and to put good comments in – because even something as small as a batch file can end up being a key part of the enterprise strategy.

It proved to me (again) that I’ll always enjoy hearing about a topic from someone who is both passionate and knowledgeable, someone that has put some effort into making it do tricks.

I taught myself programming with Quick Basic (started with Turbo Basic but couldn’t find a book on it, so bought QB – best $90 I spent I think!) and I’ve used most of the versions of VB and VB.net since then. The language is comfortable to me and especially with .Net the sense of not being able to do some things that other languages (C and C++) has gone away. Typically I’ve written code to solve business problems of one kind or another, and mostly VB has served me well. When C# came out I wasn’t thrilled about moving out of my comfort zone for a language that compiled down to the same stuff at the end of the day.

Saying one is better the other is arguing Ford versus Chevy. Far more about preferences than anything else. If I could do 20% more, better, whatever – I’d be interested in changing, but short of that and that VB is still mainstream, why change?

But…not that I’ve changed, but recently I had to spend a few days modifying a web site written in C#. Frustrating couple days because I didn’t invest ahead of time in learning more of the differences. Figured I could get through it and I did. Concepts I get, syntax – wow, did that hurt. Case sensitivity, brackets instead of parentheses, parentheses on methods, semi-colons, different look to page events. All relatively minor changes, but together it easily took twice as long. I was basically taking some existing code from another app, making some changes, plugging into the new one. Using a VB to C# converter helped some, but often I just had to struggle with it to get it to work.

Not sure what lesson to learn from it. Even as I grasped the differences I didn’t see any place where the code seemed better, just different. Having to use brackets for if/then reminded me of the miserable begin/end in TSQL – it’s something the compiler should just figure out! I didn’t do anything advanced enough to probably see any interesting differences. Mostly it left me wanting to go back to the speed and comfort of the tools I know. Should I spend more time to be closer to bi-lingual? Or be content with what I’ve learned and learn more if I need to? The latter seems easiest, but right? Best?

If use VB or C#, try switching to the other for a day – and then let me know what you thought!

I was doing some maintenance on the SQLSaturday web site recently and one request kinda low on the list was to try using Bing Maps. We’ve been using Google Maps (see SQLSaturday #17 for an example) because it’s easy to use. Just enter the address and make sure it’s the one you want, then click “Link” in the upper right hand menu and copy the HTML, giving you something like this:

<iframe width="425" height="350" frameborder="0" scrolling="no" marginheight="0" marginwidth="0" src="http://maps.google.com/maps?f=q&amp;source=s_q&amp;hl=en&amp;geocode=&amp;q=225+S+Westmonte+Dr,+Altamonte+Springs,+FL+32714&amp;sll=37.0625,-95.677068&amp;sspn=46.764446,78.662109&amp;ie=UTF8&amp;z=14&amp;iwloc=A&amp;ll=28.671085,-81.388779&amp;output=embed"></iframe><br /><small><a href="http://maps.google.com/maps?f=q&amp;source=embed&amp;hl=en&amp;geocode=&amp;q=225+S+Westmonte+Dr,+Altamonte+Springs,+FL+32714&amp;sll=37.0625,-95.677068&amp;sspn=46.764446,78.662109&amp;ie=UTF8&amp;z=14&amp;iwloc=A&amp;ll=28.671085,-81.388779" style="color:#0000FF;text-align:left">View Larger Map</a></small>

Not  much to look at but it works, no code. We’ve got a column in event table where it’s stored, making it easily and nicely data driven. When I added the task my thought was it only going to consist of changing the prompt in the setup to “bing”. No…..

Turns out that Bing doesn’t provide that same kind of support, that I could find at least. Putting a link to the map is easy, but a live working map seemed to require code. I found a couple of blog posts like this one and groaned, didn’t really want to put time into it. Finally convince myself on a Sunday morning that it would be a good learning opportunity and off I go.

If you look at the code in the post I just referenced they are calling a JavaScript function in the Body OnLoad event. That’s easy enough to copy, except – I’m using master pages (a easy way to apply consistent elements to each page) and the master page has the BODY tag. I don’t really want this function running on every page when it only applies to one. Finally I ask the right question and end up with this in the Page load event:

'only run map code if we have the data
If Me.lblLatitude.Text <> "" And Me.lblLongitude.Text <> "" Then
    Me.ClientScript.RegisterStartupScript(Page.GetType, "Startup", "<script language='javascript'>try { GetMap();} catch (error) {}</script>")
Else
    Me.BingMap.Visible = False
    Me.litMap.Text = oEvent.MapURL
End If

For those less code inclined by the time this runs I’ve already loaded and displayed the lat/long from the database (stored as varchar if you’re wondering) and now I’m branching based on whether those values exist. That is to avoid breaking all the old events that have the Google code stored. The meat of it is the RegisterStartupScript that ultimately adds the call to the GetMap function in the Body OnLoad event.

Then, I need to add some JavaScript to the location page. I think this can be injected at runtime as well, but since it won’t change much, saw no reason not to embed it:

<script type="text/javascript" src="http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.2"></script>

<script type="text/javascript">
   var map = null;
   myBingZoom = 14;

   function GetMap() {

          try
              {
                var myBingLat = document.getElementById('<%=lblLatitude.ClientID%>').outerText;
                var myBingLng = document.getElementById('<%=lblLongitude.ClientID%>').outerText;
                var divtag = document.getElementById('<%=BingMap.ClientID%>');
                var mybirdWaypoint = new VELatLong(myBingLat, myBingLng);
                map = new VEMap(divtag.id);
                map.LoadMap(mybirdWaypoint, myBingZoom);
                map.AddPushpin(mybirdWaypoint);
                }
           catch (Error)
              {
              }
   }
</script>

And then in the page where I wanted the map, added this:

<div id="BingMap" style="position:relative; width:400px; height:285px;" runat="server" visible="true"></div>

Now if you know what you’re doing that’s about 10 minutes worth of work. Took me 2 hours to get it all done. If you decide to try this remember that JavaScript is case sensitive. Case Sensitive. CASE sensitive. Next, Visual Studio 2008 will debug client side JS if you enable debugging – which strangely enough is a browser setting and not in VS – but a real help, very cool feature.

You’ll see two lines that get the lat and long from the controls. Maybe there is an easier way, but this was the example I found and went with it. The “getelemementbyID” exists to translate what I called the lat/long controls at design time to what they were finally called by asp.net when the entire page was rendered.

One other note. In my case I only wanted to show the map if I had lat/long, but originally it still took up space on the page. The answer was to add “runat=Server” to the div tag so that I could flip the visible property to false in code as needed, eliminating the white space it was reserving.

I haven’t found a solid way of getting the event lat/long yet, though I can’t say I’ve looked deeply. Sometimes it shows up in the Bing URL (I think). Found this site that provides them using a few difference sources, but none of them seemed to be quite right when I plugged in values for SQLSaturday #16 (example here).

It was an interesting project and while not necessarily the best use of my time when I look at now versus then, it may lead to something more interesting like being able to map all of the SQLSaturday events easily on one map. But that’s on the list for another day!

I read Andrew Binstock occassionally in SD Times and in the most recent issue he posted a list of guidelines (which in turn was excerpted from 'The Thoughtworks Anthology') for learning to write "real" object oriented code. Read Getting the knack of OO Coding and see what you think. Some of it seems a little over the top, but it is an exercise I guess. I know it does make me wish for a similar concept in SQL (TSQL). Not to teach object oriented style in TSQL (bad I think), but rather a way to really drive early learners to use the language fully and elegantly. Have to think on it a little, maybe I'll try - anyone else got ideas on this?

SDTimes has an article up about Debunking Cyclomatic Complexity that talks about the results of some research that supports what I suspect most of agree with - more lines of code per module/method leads to more bugs. Object oriented program has done a great job in leading away from procedures that have 500 lines of code down to 50 or less (we're nowhere close to winning that battle in TSQL!). But the interesting part was that more complex code didn't correlate to more bugs, and speculates on some ideas about why not - I'll leave that for you to read.

Seriously, on the TSQL side you see what are relatively trivial procs on one side (which are fine and useful), and on the opposite extreme you see almost entire programs written in the context of a single proc. There is real value in breaking up those monoliths that are easier to read, test, and possibly even reuse.