Wednesday, 08 September 2010
Here's another thing I learned when preparing demos for a non technical crowd on Office 2010. Putting videos into PowerPoint can actually be fun. My exposure to these was mostly at large keynotes and so on, where the speaker would play a video and stand there kind of awkwardly while it played. Not my thing.
Now, have you ever been at a party or get together that had a slideshow of pictures playing? Weddings, wakes, milestone birthday parties, seems like you can almost always spot a laptop in the corner just quietly cycling through dozens (or hundreds) of pictures. It's actually a really nice trend. Most of the people I know do that with PowerPoint. One picture per slide - sometimes filling the whole slide, sometimes with some text added - and then set it up to auto advance and to repeat indefinitely. Well, if you're going to do that, you can include videos as well. And PowerPoint has some built in tools to let you crop (or clip) the video, fade it in and out, even display it in a slightly more interesting layout.
I can see adding videos to my next slideshow using these tools. And not having to open a second product will make it that much more likely that I'll actually do it.
Monday, 06 September 2010
Earlier this summer I was invited to talk to some non technical users about Office 2010. As always happens when I am preparing new material, I learned something. My problem is that I often learn how to do things and then figure I'm done, I know how to do that. But software changes and sometimes the 11 step, 3 application approach that I've learned gets superseded by a much simpler way.
Here's an example: let's say you're putting together a Word document, but it's not a requirements document or a specification or a response to an RFP. It's something a little more personal, a little less technical. It has actual photographs in it. Not screen shots, not a GIF exported from Visio, a photograph. You have the photograph, but it's not quite the right size, or perhaps it's too dark, or too light. You need to fiddle with the contrast and such. If you're a geeky person, you probably have various apps installed on your machine that can do that. So you open the photo in app 1, do something to it, maybe also in app 2 and do something else, and then finally you paste the picture into Word.
Well that process is just old school. Word can do all kinds of neat stuff right from within the app. Try it! Paste in a picture that needs some tweaking. Then select it, and click on Picture Tools.
You can adjust brightness and contrast with a live preview. Or try out the Artistic Effects:
This is a lot quicker than fooling around with multiple applications, and makes this sort of document fun.
Saturday, 04 September 2010
Back in July, I mentioned that my Extending Visual Studio course for Pluralsight was live. As I completed the course, it just kept growing and growing, so in the end it became two courses.
Customizing and Extending Visual Studio 2010 Without Code covers macros, snippets, templates, and so on - ways that you type stuff into a file, and thus make Visual Studio behave differently, but don't actually write C# or VB or C++ to make that happen. The modules are:
- Overview of Visual Studio 2010 Extensibility
- Why write extensions for Visual Studio?
- Visual Studio Macros
- Visual Studio Snippets
- Getting and installing extensions for Visual Studio
- The Visual Studio 2010 SDK
- Visual Studio Start Page
- The VSIX Format
- Deploying Templates
Customizing and Extending Visual Studio 2010 by Writing Code covers the rest of the story - cases where you actually write and compile code (in this course, the demos are all in C#) and thus make Visual Studio behave differently. The modules are:
- MEF, The Managed Extensibility Framework
- Writing Editor Extensions
- Testing and deploying editor extensions
- Visual Studio Add-Ins
- Visual Studio Packages
- Extending Modeling and Diagramming tools
Together, these courses total 9 hours. Please let me know if they help you!
Thursday, 02 September 2010
I'm having a Coffee and Code of my own in downtown Toronto on September 23rd all afternoon. Actually, I'll start at 11 and be there until 6 to catch the "stop by after work" folks. If you've heard of Coffee and Code at all, you know how this works. If you haven't, I've made a page on our web site about it
. Just drop in and ask me "Is it true that the C++ language is getting new keywords and stuff? How can that be? And does it really matter?" or "Do you have the Windows Phone 7 tools installed? Can you show me an app on the emulator?" or "Is Visual Studio 2010 really nicer than Visual Studio 2008?" or "What local user group meetings should I be coming to?" or whatever else is on your mind.
So stop by any time between 11 and 6 on the 23rd to the Starbucks at Yonge and King. I'll be at the big table at the back, just walk up and say hi. We'll talk about whatever is on your mind, maybe some of you will talk amongst yourselves, maybe you'll show me what you're working on. I'm looking forward to it!
Tuesday, 31 August 2010
Let's say you read the entry about data structure visualizers
and in addition to all the STL humour you got excited about being able to control the way the debugger shows your objects as you work at understanding your application at runtime. And then you were sad because you don't do native C++ work and you don't know how you could get the same behaviour in a managed application. Well, have I got a keyword for you - DebuggerDisplay
. Don't like that MSDN page about it? Here's another
. Quick and easy, at least for simple types with only a few member variables. Give it a whirl. There's a nice example
with screen shots at Dev102.
Sunday, 29 August 2010
I somehow missed this John Robbins blog post
from back in May. He calls out an excellent presentation on writing data structure visualizers presented at BoostCon 2010. Here's the title slide:
Oh yes, this is a fun talk. I wish I had a recording, but the slides alone are entertaining and useful. I am already planning to put some of this code into practice, and I must find time to check the other talks, too. The links are in John's blog post.
Friday, 27 August 2010
As a new school year starts to roll around I naturally pay a little more attention to articles about undergraduate education. I'm once again teaching a one-term course on Object Oriented Design and UML at Trent University in Peterborough. This is of course just one piece of the curriculum. Trent is an interdisciplinary place and its graduates are expected to understand the concepts that underpin what they're learning. In fact this is what I see as the main difference between those with a university education and those without (though there are exceptions on both sides.) It's one thing to learn, perhaps by rote, the steps required to make a certain kind of application, and it's another to understand what you are doing and why. The latter kind of person generally finds it easier and easier to learn new things, connecting them to things already known, while the former finds it harder and harder as a mass of seemingly-unconnected facts moil around in an overly-crammed head that feels ready to explode.
I approve of valuing concepts over specific how-to's. It's hard work keeping up with the very latest technology when all you're doing is using it. It's even harder when you're also working on concepts and trying to teach. I don't expect a university to teach students how to use a specific user interface framework (MFC, Winforms, WPF, whatever) -- I expect it to teach them user interface concepts, illustrated with some framework the prof happens to know that's generally available. The students can then learn a variety of UI frameworks over their careers. But that doesn't mean I approve of all the ways in which programming as part of undergraduate education varies from programming in real life. Two specific variations I have a problem with are team size and problem size.
In real life, it's rare to work all alone, all the more so when you've only just graduated. Most university computer science grads will join a team of 2-10 developers reporting to a lead of some sort, with various people from QA, user reps, the business people and so on having various positions of semi-authority, semi-teammate in relation to them. Yet undergrads are generally expected to work alone on all projects and never discuss them with anyone until handing them in.
In real life, problems are not well specified, certainly not as tightly as undergrad assignments are. Most importantly, in real life user input is bizarrely ill formed. Users type letters where numbers belong, leave mandatory fields blank, even deliberately construct complicated bad input as part of hacking attempts. Yet most undergrad assignments do little or no input validation or error handling unless those are the point of the assignment. And of course, most undergrad assignments can be completed by an inexperienced programmer working alone a few hours a week (10 at most) in a week or two while most real problems take weeks and months of work by one or more dedicated resources to produce even a preliminary solution.
Trent (and I presume most other universities) addresses these issues with a fourth year course in which a team of students works on a real problem for an outside entity - usually a local firm or charity. They must gather requirements, code, test and implement a solution, and present to their peers and professors a summary of the project. Some students benefit immensely from this, though most take on far too big a challenge and struggle to complete it.
My contribution is to point out to my students where things are being simplified for them, where things would be vastly different in real life. Undergraduate courses simply cannot be the same as on the job training, and I don't want them to be. I want my students to be learning concepts and underpinnings as much as language syntax and how to work particular tools. But I want them to understand that when they start to put all this to use, things will feel very different than they did during class time. An assignment from your boss and an assignment from me are very different. (I've blogged before that in real life, you don't get 7/10
, you have to keep doing it until it is right.)
I don't have all the answers. Lots of people muse about this stuff. Here's the inventor of C++ on the same issues
. Easy to complain, hard to do anything about it, but we can all do our bit.
Wednesday, 25 August 2010
I mentioned Hilo when it was first released. This is a cool project doing Windows 7 development in native C++ with no frameworks - not MFC, for example - so you can really see just how it is done. It's not just code, it's also a walkthrough of their design thoughts, and explanation of that code.
The next application, Hilo Annotator, is ready. It features a ribbon, it uses the Windows Imaging Component, Direct2D, and so on. While you probably don't need an image annotator, you may find the code useful in your own applications. And remember, this is all native C++ code.
Your best place to start is the Visual C++ Team Blog entry about it. It's rich in links and has a nice screenshot too.
© Copyright 2017 Kate Gregory
Theme design by Bryan Bell
newtelligence dasBlog 2.3.9074.18820
| Page rendered at Wednesday, 13 December 2017 05:48:21 (Eastern Standard Time, UTC-05:00)
On this page....
Pluralsight Free Trial
Click Subscribe, then Start 10-Day trial