# Friday, May 12, 2006

Jerome Carron from Microsoft will be coming to the East of Toronto .NET User Group May 17th to talk about mobile applications:

This session will be an introduction to developing Windows Mobile applications with Visual Studio 2005. The focus of the session will be on Devices and the Mobile platform, getting started with device development (user interfaces and controls), data management (SQL Server Mobile) and Visual Studio tools for Data Management and close out with a look at Windows Mobile 5.

This meeting will be at the Whitby Library. Please register so we're expecting you.


Friday, May 12, 2006 4:19:33 PM (Eastern Daylight Time, UTC-04:00)  #    
# Thursday, May 11, 2006

Jean Rene sure knows how to run a conference. In previous years he has bought women's-sized shirts for the women speakers, but this year he even got us a different colour scheme! Here are Julie and I modelling them:

I just love coming here!


Thursday, May 11, 2006 9:21:43 AM (Eastern Daylight Time, UTC-04:00)  #    
# Wednesday, May 10, 2006

Rory blogged what I was thinking... "SEVEN PILLOWS HOTEL WHY???!!!?!"

And then his pictures prove that the bed he faced and which lit this question in his brain is in fact identical to the bed I faced last night myself. How scary is that? Rory is not at Devteach, is he?

My guess (nay, I'm pretty sure it's my fervent hope) is that he is at another Marriott somewhere else and not in my room here in Montreal taking pictures and blogging.


Wednesday, May 10, 2006 3:50:00 PM (Eastern Daylight Time, UTC-04:00)  #    

In my concurrency talk today I had a total brain freeze and could not remember the last name of the author of the concurrency book I wanted everyone to read. The title is Concurrent Programming in Java: Design Principles and Patterns and the author is Doug Lea. Don't let the word Java in the title fool you: this is a book that explains the concepts of concurrency no matter what language you're going to use in the end.


Wednesday, May 10, 2006 3:45:00 PM (Eastern Daylight Time, UTC-04:00)  #    
# Tuesday, May 9, 2006

The ISO C++ committee is working on the next standard for C++. At their April meeting, a number of items were added to the working draft, which means they will almost certainly end up in the standard -- it's just a matter of final agreement on some of the subtle details of the item, rather than whether it should be there or not. As Herb Sutter reports, the items that were added are:

  • TR1, a pile of library changes (as opposed to the language itself) including various new kinds of smart pointers
  • declaring variables but letting the compiler deduce their type instead of doing it yourself (auto type deduction).
  • delegating constructors
  • the > > vs >> subtlety that Brandon referred to in his recent Channel 9 interview. Visual C++ takes care of this already, but now it's being added to the standard.
  • extern template

Now why should an ordinary programmer care about the machinations of the standards committee, and something that may or may not get approved this decade? Well for one thing, the compiler vendors don't wait for the standard before they implement the new keyword or the new functionality. And for another, it can give you a hint about what's headed your way. Let me tell you what I mean.

Here are Herb's examples of auto type deduction:

auto x = 3.1415926535;
auto i = container.begin();

In this case, x has type double, and i has type map<string,unordered_map<int,tuple<float,string,const int> > >::const_iterator or whatever the right type happens to be, without having to spell it out.
Now in and of itself this is a cool feature, especially for C++ with heavy STL use. Another thing Brandon talked about in his Channel 9 spot was how foreach saves us from having to declare those iterators, set things to begin() and so on, and there's no doubt that figuring out the types is part of that pain. But go beyond that for a moment. I have seen plenty of auto-type deduction examples in C# over the last year or so, and they were all LINQ examples. Does this mean C++ will get getting LINQ too? At least one language barrier to LINQ will be going. Let's see what else happens.

Tuesday, May 9, 2006 7:21:11 AM (Eastern Daylight Time, UTC-04:00)  #    
# Monday, May 8, 2006

I'm guessing that when Channel 9 came by to talk to Martyn Lovell, they got Brandon to agree to be next. His interview has been posted and has some cool quotes in it:

  • "I only learned C++ about 4 years ago"
  • "Visual C++ is the only language that can get to every API Microsoft ships"
  • "C++ is the most widely used language in the world, and it's not going anywhere"

He discusses verifiable code, his favourite new language features, and templates-vs-generics as well. Take a look!


Monday, May 8, 2006 8:33:57 AM (Eastern Daylight Time, UTC-04:00)  #    
# Sunday, May 7, 2006

The title of this post comes from a staff member at a client of mine. We were discussing a possible project and the staffer was showing me how they did a particular task. They were using a web app that was going to a lot of trouble not to look like a web app: the users all had a shorctut on their desktop to launch a browser pointed at the site, most of IEs toolbars were suppressed so you didn't think you were even in a browser, and so on.

She performed a search, but before clicking the button she copied her search terms from the textbox, opened a blank Notepad, and pasted them in. "I'll explain that in a minute", she said. Then she clicked the button, and followed the link to the first search hit of twelve or so. On that page she made a small change, or noted down something she saw, something minor anyway. Then she said "Here's the frustrating part." There was no link back to the search results and the IE toolbars were all suppressed. So she used the nav bar links to go back to the home page, from there clicked a link to the search page, pasted in the search terms she had saved, did the search again, followed the second link this time (and the designer didn't like visited and non-visited links being different colours so she had to remember which one she was on) and round and round again.

So I asked "why don't you just use the Back key?" "What Back key?" She was on the second result, and I reached over and pressed Backspace to take her back to the search results. That's when she said "You just saved me an hour a day!" She didn't hug me, but she did something just as good -- ran around the office telling everyone else what she had learned. That particular project didn't fly, but I still do lots of work for that client. And those five people all have an extra hour a day for the rest of time.

What do you know that you're not telling users? Keyboard shortcuts, context menus, alternate ways to do simple tasks... share it!


Sunday, May 7, 2006 12:17:38 PM (Eastern Daylight Time, UTC-04:00)  #    
# Saturday, May 6, 2006

I have a mentoring client who is doing a fair bit of Sharepoint work. Some of it I just do for them and install on their servers, but I'm working closely with a team of developers who are building up their skills on both development and administration, and putting sites into production for real people to use to do their jobs.

This client is a pretty large firm - a Canadian household name - and so in addition to a large team of developers they have an infrastructure team, the "downstairs guys" who configure and support all their servers. As the number of Sharepoint sites grows, we're having strategy meetings with developers and infrastructure people about how to handle the growth of Sharepoint within the firm.

So at one point in this meeting the infrastructure person says to me "I need some sort of reports, some way to know how big a site is getting. I can look at the size of the SQL database but it's not very accurate. Or when we do the backups I can look at the size of the backup file. But then how can I tell what the issue is -- maybe someone has turned on versioning or something else that eats up disk space." Various people in the room start talking about the Sharepoint object model, about pointing SQL Reporting Services at a Sharepoint data source, and other developer approaches to the problem.

Now earlier in the meeting several of the developers had been telling the infrastructure person that he has to come to grips with Front Page. There are some things that are really hard to do any other way, and really easy to do with Front Page. And as a result I had Front Page open on my laptop and had opened a site (our own Gregcons internal site as a matter of fact) but hadn't done anything in it. So during this conversation about how to know the size of the site, I clicked the Reports button on the bottom Front Page toolbar that shows when you've opened a web:

And what do I see when I click that?

I grinned and spun the laptop around so that the infrastructure person (and his grandboss, who was at the meeting with us) could see it. "You're going to have to learn to love Front Page," I told him. And to the grandboss I said "aren't you glad you have a consultant?"

A lot of times I work really hard and long to bring my clients value. But there are so many times when I can do something in 30 seconds that the client would have spent days doing another way. I love those times.


Saturday, May 6, 2006 7:46:36 AM (Eastern Daylight Time, UTC-04:00)  #    
# Friday, May 5, 2006

Say you have an application that uses P/Invoke (the DllImport attribute on an external method defined in a native DLL) to access some particular functionality. A lot of the use for this feature is to get to something in the Windows API that isn't exposed by the .NET Framework. But there are also folks using P/Invoke to call their own code from their own DLLs. The question then arises: where should you keep that DLL you're using (oh, please, not System32, anywhere but System32 -- years ago a buddy said "the registry is a giant and complicated database that tells you all your COM objects and DLLs are in System32") and how is it going to get deployed from your computer to wherever you install it?

If you try to add a random file to your manifest on the Publish tab of a Visual Studio 2005 Winforms project, you will discover there really isn't a way to do it. The file has to be in the project. You can add things to your manifest with MaGeUI (Manifest Generator with a User Interface, so named because MaGe is entirely command-line) which you can run from a Visual Studio command prompt, but most of us want to manage our manifests with Visual Studio. Heck, you could edit your manifest with Notepad -- it's only XML -- but that's not what I'd call the popular choice.

You could add the DLL to your project, but if it's under development, you're going to have to hand-update your copy when it changes, or your tests won't be accurate. And for a lot of folks, adding it to the project is going to mean adding it to source control, and binaries in source control does not sit well with me. Here's a better way.

Start as though you were going to add the DLL to the project. Right-click the project in solution explorer, Add, Add Existing Item, browse to where the DLL is, change the file type to All Files or Executables, click the file name - but don't click the Add button. It's a compound button, so click the little Arrow next to Add and choose Add As Link.

You should see your file added to Solution Explorer with a sort of shortcut symbol:

Click once on the DLL then bring up the properties for the file. Make sure Build Action is set to Content and Copy To Output Directory is set to Copy If Newer. (If the DLL is on the network, and you're working offline, on a plane or something, and you've built once so you have a copy already, you can flip this setting back to Do Not Copy so your builds don't fail.)

A word about "where the DLL is". If you develop alone, this can be some sort of c:\working\clientname\projectname idea, but for a team, that's not going to work. This path is going into your project file and you'll check it in to source control and the rest of the team will be using it. Unless you all have the same folder structure, you're going to want to use a UNC name. It's probably best to point it at a share where you publish the DLL after you build it.

Having added the file to the project, you can now make it part of what you publish. Click Application Files on the Publish tab and you should see it there. You might need to check the Show All Files box, but I didn't:

This isn't available in every kind of project -- I can't do it in a C++ WinForms app, for example -- and it doesn't really work for an ASP.NET app where there is no project file, just the folder. I think for those a pre- or post build step to copy the DLL from where you build it or from the share where it is published for all developers to use would be the way to go.


Friday, May 5, 2006 7:38:03 AM (Eastern Daylight Time, UTC-04:00)  #