Friday, 19 September 2008
Microsoft Canada is trying something different this fall and winter. A paid conference featuring material from this year's TechEd USA, delivered by excellent local speakers and coming to a city near you. Some cities have two day events, others a single day.
- Toronto, October 29th and 30th
- Montreal, November 6th and 7th
- Ottawa, November 27th
- Winnipeg, December 4th
- Calgary, December 10th and 11th
- Halifax, December 17th
- Vancouver, January 21st and 22nd
What will the talks be like? What will it cost? Will there be cool swag? The web site doesn't really say right now, but I've been told the talks will be actual TechEd talks, the speakers will be industry leaders (my friends and colleagues, maybe me if we can make the dates work), and there will be 5 or so tracks, meaning over 30 sessions, so something for everybody. The early bird discounts will be substantial, so watch that web site for updates!
Thursday, 18 September 2008
Some time ago a prospect called me to ask if I could help him solve a really frustrating problem. He had some software that was working and that he had delivered to dozens of clients, but sometimes it froze. It featured a lot of timers and he thought the problem was that one of them stopped firing, but he wasn't really sure. Could I do a code review for him and find where he had been stupid or sloppy to cause this problem?
So this is an intriguing concurrency problem, because multiple overlapping timers are not something you can definitively test, so I answered him "sure, send me the code." He sent it along and unfortunately it was really quite well written. That's unfortunate because I couldn't point to some obviously sloppy or stupid code and say "fix this and all will be well." We gave him some advice about how to gather problem information from users when they reported that one of the clock/timers "froze", and wished him luck.
Months later he came back, saying that it was a distinguishable subset of his clients that were having the problem, and please could we look again? He sent us the source code, as well as a deploy package that had gone to the most recent client to experience the problem. At first, we couldn't build his source code, because he had a whole pile of custom controls and funny license files and so on. So while we were waiting for him to send us things, we played with the executable. We couldn't make it misbehave. If repro cases don't come easily I usually switch to reading the code and imagining what could cause what I'm seeing, but when that doesn't work I'm back to trying for a repro. We were hoping it was having some sort of leak - memory, handles, something like that - which was freezing or hanging it. Repeated perusals of the source code convinced us the timers were a red herring, leaving mystery leaks as our best guess.
Did you know you can get Task Manager to show you more than just memory and CPU usage for your applications? On the View menu, choose Select Columns:
Then check off what you want, such as Handles and GDI Objects. Now watch while the application runs:
In this case, the deployed application didn't have a memory or handle leak, but it did seem to have a GDI Objects leak. The count kept going up, and never went down. We even discovered a way to make it go up -- there were buttons in the UI forming a toolbar of sorts, and they had a special effect as you moused over them and moused off again. Every time we caused the special effect to fire, the GDI Objects count would go up. This is the sort of thing that's impossible for developers to repro, because we don't idly wave our mouse back and forth along a toolbar wondering which button we should click. We test for like 5 minutes and say "looks ok to me." But we had been told that the freezes generally only happened when the application ran longer than usual - 4 hours rather than the usual 2 or 3. So we were hoping for some sort of leak that generally had no consequence, but could kill you if you waited long enough. So having learned how to drive the count up, we sat there waving the mouse around and driving it up. When we drove it past 10,000 - the application froze. Yay! Repro!
So we went into the source to reproduce it under the debugger - but the version we built from the source he sent didn't show the same behaviour - the GDI Objects count was well behaved and went up and down a little bit, never getting anywhere near 1,000 never mind 10,000. And interestingly, the source code he had sent us just used regular buttons in that toolbar like area. Aha! I blame the special button.
I asked him, since I didn't have the source for the version that was freezing, to tell me more about the button and where it came from. He told me the name and the URL from which it was downloaded. I went there and got a version number and file name, and confirmed he was running the most recent version available from that site. He also told me that now that I mentioned it, the only folks who'd reported freezing were the folks for whom he'd included the special button. So I knew it had to be the culprit. Time for some searching. Several people claimed that control had a "memory leak" problem. What's more, the developer of the control had released a newer version, which hadn't been mirrored over to the URL our guy found it from.
I told him all this, he went and got the newest version of the control, built the solution, and indeed the GDI count is now well behaved, and no-one has been able to make the application crash, freeze, or hang ever since. (I sat on this story for a few months to be sure.) So there you go, problem solved! I wouldn't have thought it was possible when we started. The moral for me is to use all the tools you have, and to use them fully. This problem was solved with Task Manager, an insistence on trying to reproduce the problem, and Live Search. Phew!
Wednesday, 17 September 2008
A recruiter called me looking for an architect. I would be a good fit for the job if I was available - I have tons of Internet programming experience, architect systems all the time, services and desktop among others, and as for quiet confidence and entrepreneurial spirit, those describe me just fine. But I'm not available. It occurred to me that a reader of my blog might be. So if you're interested, please contact the recruiter. Good luck!
A software firm (30 people) in downtown Toronto is looking for a full-time architect to help build its next generation of Email System.
The organization is a divsion of a large U.S. based firm with a CEO with a track record of successful entrepreneurial start-ups and exits.
The firm develops applications within Microsoft Exchange and requires an architect with the following skills:
- A high-level design capability as well as the willingness to be hands-on within the development cycle
- Experience building applications within Microsoft Exchange, using MAPI, Active Directory
- Experience building applications around Microsoft Outlook
- Service oriented backend infrastructure
- SMTP expertise
- Desktop application and integration development experience
The right person should have a passion for coding and building systems, have quiet confidence as well as an entrepreneurial spirit.
If you are interested, or know of someone that might be appropriate, please contact Mike Fox at firstname.lastname@example.org or 416-406-1777.
Tuesday, 16 September 2008
Monday, 15 September 2008
At the moment I only have one fall speaking commitment settled and it’s one of my favourites - Tech Ed Developers Europe. Barcelona will be warm, both in the temperature sense and the personal interaction sense (though I do predict exposure to pocket-picking, bag-lifting, and other forms of theft once again). The attendees will be energetic and appreciative. The other speakers will be fun to hang around with. The ancillary events will be fun fun fun.
My topics are the Vista Bridge, and some new C++ features. We’re still working on the abstracts and titles, so I’ll post an update when they’re locked.
See you there!
Sunday, 14 September 2008
This year we FINALLY get a PDC. I have been looking forward to it for a long time, but booked my attendance and my flights during one of this year’s blogging hiatuses (hiati?). If you are responsible for any kind of strategy or planning, if you are starting a project that will take several years to finish and you want to use the latest technology while you’re building it, or if you just love making software and can’t wait to see what’s next, then the PDC is for you.
It’s the last week of October, in Los Angeles (the only thing about it I don’t really like) and it will just cram your brain with information you actually can’t use to write code quite yet -- but that you really need to plan your own roadmap over the next few years. If you want to know something about a product that is already shipped (say, Visual Studio 2008) then this is not the conference for you. Even if your area of interest is software that is mostly written, maybe has a CTP out already, and will be released during 2008, then again, PDC is not really going to help you. PDC is about stuff that is just starting now. PDC is about getting a big headstart on those who waited till a product was released or a public beta was available. Here’s the list using their own keywords (the numbers are how many sessions are on that topic)
|Ad Platform 
Cloud Services 
Dynamics CRM 
Entity Framework 
Internet Explorer 
Live Mesh 
Live Platform 
SQL Server 
SQL Server Data Services 
Sync Framework 
Unified Communications 
Virtual Earth 
Visual Studio 
|WCF  |
Windows 7 
Windows Home Server 
Windows Mobile 
Windows Server 
Wow - 27 sessions on cloud stuff? Pay attention.
I also chose a random session so you could get an idea of the level of conversation PDC is for:
Unified Communications: Futures
Kyle Marsh, Chris Mayo
In this session we unveil the future of Microsoft Unified Communications (UC) technologies. Be among the first to see the UC roadmap, watch the new features in action, and walk though the code that makes it all possible. Come see how you can deliver breakthrough applications by embedding rich presence, build click-to-call features including voice and video, create communication workflows using speech and IM, and integrate Microsoft Exchange 2007 features and data.
Tags: Advanced, Unified Communications
This is one of the few conferences in the world that I get myself to (that's right, my own money) as an attendee. I'm not there to speak, work a booth, or be on a panel. I'm there to learn, and you should be too. See you there!
Saturday, 13 September 2008
Or put another way, is VB just C# without semi colons? Well, yes and no. If you work in the big wide world of many different programming languages, frameworks, libraries, and operating systems then C# and VB are so close as to be almost indistinguishable. They both have great support from Visual Studio, they both produce managed code that runs on the CLR, they call the same framework functions, they have keywords for the same CLR concepts, and they both have a community of support, sample code, tutorials and the like. But those communities aren’t twinned – some samples are available only in VB, and others only in C#. For historical reasons there are a lot of C# programmers inside Microsoft, and perhaps that’s why VB samples can be a bit thin on the ground.
This less-than-100%-overlap between the samples, tutorials, and so on for the two languages results in people who are proficient in one language trying to read (or worse, write) in the other. Sometimes a great C# developer will be asked "where’s your VB sample? Quick, translate your C# one right away!". Other times a great VB developer will be trying to write their own VB code while reading samples or tutorials written in C#. It can go in the other directions, too.
But although these two languages have a great deal in common, they are different, and in more than just syntax. There are features in each that aren’t in the other. There are natural idioms, too. Idioms are a way of writing things that are natural to one language or identifiably belong to one language. Choosing an example not from the VB/C# world, but from C++ or C, it used to be just so normal to write
//do something that relies on p not being null
That’s C++, and a deliberate single equals sign. I am assigning p the return value from the function. Then I am testing that value. (Quibble: I am testing what the = operator returns, which is the value just assigned for all well written = operators.) If it’s not null, we’ll do the stuff in the braces. Sometimes I used to come across this instead:
//do something that relies on p not being null
if (p != null)
//do something that relies on p not being null
Now these other ways of doing it aren’t wrong, they will compile and work, but they demonstrate a lack of familiarity with C++ idioms, with a C++ way of thinking. They are usually written by people who aren’t very comfortable with pointers.
Similarly, in VB, I have seen more than once this sort of thing:
Dim retval As Boolean = False
If x > y Then
retval = True
retval = False
Again, that’s not wrong exactly, but it’s not what I like to write. I prefer just:
Return (x > y)
Sometimes people say I write C++ in VB, because that's a very C++ way of writing things. But I find it not just easier to read -- it's less bug-prone. (Copy and paste errors like having True in both clauses, for example, will make you crazy.) I know that it’s kind of a C++-ish way to express myself, but it feels natural to me and it works. People who are less comfortable working with Booleans tend to prefer the first, more verbose way. They can see the whole thing laid out for them. It’s not wrong, just different.
Well, it turns out those who try to write VB when they’re proficient in C# are likely to run into a lot of differences in thinking and expression when they take on that task. It might be syntax tripups, missing the use of a helpful VB feature that isn’t in C#, or just writing code that doesn’t use the VB idioms. Kathleen Dollard has amassed a huge list (77 at the moment) of things you should know if you want to write VB code. Required reading for C# people who have to write VB, entertaining for those who like VB, and what's more, plenty of experienced VB developers could learn a thing or two from it (I did.)
Friday, 12 September 2008
Vista gets a lot of bad press it doesn’t really deserve. For example, it crashes way less than XP for me. Some applications behaved oddly at first (primarily because of UAC and Virtualization) but I have either learned workarounds, such as running the app elevated, or upgraded or replaced the apps that were causing trouble. The slow file copy thing drove me insane, but SP1 took care of that. I really have very few complaints left about my computer, and the ones I have are aimed at specific applications (yeah, Outlook 2007, I am looking at you when I say that, and Adobe, don’t think not meeting my eyes will keep you out of my bad books) rather than the operating system.
Still, who wouldn’t want to make their operating system run faster and smoother? Here are some helpful thoughts and guides:
Windows Vista Performance and Tuning. A downloadable paper from Microsoft. Simple stuff here like choosing the right power management plan, using ReadyBoost, tweaking your search settings, and so on. Worth a read.
Vista Annoyances Resolved. Despite being annoyingly spread over 9 pages (see what taking ads does to you?) it has some good stuff. You’ll see explanations of SuperFetch, ReadyBoost, restore points, and more.
Roundtable with Mark Russinovich. An upcoming special roundtable on Vista Performance. Send your questions in ahead of time, then tune in for answers.
Learn a little, enjoy your daily computing life more.
© Copyright 2017 Kate Gregory
Theme design by Bryan Bell
newtelligence dasBlog 2.3.9074.18820
| Page rendered at Thursday, 23 November 2017 04:21:22 (Eastern Standard Time, UTC-05:00)
On this page....
Pluralsight Free Trial
Click Subscribe, then Start 10-Day trial