If you’re looking for the latest and greatest version of Visual Studio, you’ll want to get your paws on the Release Candidate for Visual Studio and .NET Framework 4.0! It was made available to MSDN subscribers yesterday (if you’re an MSDN subscriber, you can download it immediately), and will be available to the general public tomorrow, Wednesday, February 10.
The changes in the Release Candidate (RC) are based on your feedback from the Beta 2 version and include improvements to:
General UI responsiveness (including painting, menus, remote desktop and VMs)
Editing (typing, scrolling, Intellisense)
Designers (particularly Silverlight and WPF)
Memory usage
Debugging (stepping, managed/native interop)
Build times
Solution/project load times
Here’s a Channel 9 video featuring Visual Studio General Manager Jason Zander talking about how the Visual Studio team addressed the feedback you gave for Beta 2:
The team has tested the RC on all the projects they could get their hands on, but not all the projects in existence. That’s why we’re making the RC build freely available to you so you can try it out on your projects! We want to hear from you, so please give the RC a try and let us know what you think via our survey site.
In the meantime, the Visual Studio team is working closely with vendors who’ve created popular Visual Studio add-ins, such as Resharper, CodeRush and so on to make sure that Visual Studio 2010 works with them.
Update: An Extra Note from Scott Guthrie
Our goal with releasing the public RC build today is to get a lot of eyes on the product helping to find and report the remaining bugs we need to fix. If you do find an issue, please submit a bug report via the Visual Studio Connect site and also please send me an email directly (scottgu@microsoft.com) with details about it. I can then route your email to someone to investigate and follow-up directly (which can help expedite the investigation).
Last week, I presented Kodu (pronounced “Code-ooh”) to a group of teachers and high school students at Corpus Christi Catholic Secondary School. Kodu is a system created by Microsoft Research for programming videogames without using a traditional programming language; instead, you use a combination of menus and visual programming. It was designed to be a gentle introduction to programming that would appeal to children, but many adults – myself included – have ended up getting drawn into it, spending hours constructing and tweaking game worlds.
Kodu’s a little tricky to describe – it’s one of those things that’s much easier to show rather than tell. Here are a couple of videos that should give you a bit of Kodu’s flavour. First, here’s IGN’s look at Kodu:
Kodu was designed to be programmed with the Xbox 360 gamepad, which you can use if you’re programming it on the Xbox 360 or a computer (if you’re using a computer, you’ll need either a wired Xbox gamepad plugged into one of its USB ports or a USB adapter for your wireless Xbox gamepad). If you’re using Kodu on a computer, you have the additional option of using the keyboard and mouse.
This is the first of a series of articles on Kodu programming that will appear here from time to time. If you’ve got kids (or know some) who are curious about programming, or if you’re looking to try a completely different kind of programming, get Kodu on your Xbox or PC and give it a try!
In this first installment, I’ll show you how you can build a simple little program that lets you drive an avatar around a small world. In later installments, I’ll show you more game-like elements and the “code” for a game of mine called “Stupid Sparkling Vampire Game”.
Touring Teran00bia
In addition to a programming “language”, Kodu provides you with tools for editing the worlds in which your games take place. I often start with a simple, no-fuss world that I created called “Teran00bia”. It’s a small, flat square world suitable for experimentation. If you have the Windows version of Kodu, you can download Teran00bia here. I can also share the Xbox 360 version, but you have to “friend” me on Xbox Live first – my gamertag is “Accordion Guy”.
Teran00bia is a blank slate, a world with nothing in it. Here’s what it looks like when you load it:
In this exercise, we want to stick a single character – Kodu – into the world and allow the player to drive him around using the controller’s left stick.
To start programming, get into Edit Mode. Press the “Back” button on the gamepad to switch to Edit Mode. Your screen should now look like this:
In Edit Mode, the left thumbstick moves your “cursor” (the purple “donut”) around the world, while the right thumbstick changes your camera angle. You use the left bumper (that’s the button just above the left trigger) to zoom out and the right bumper (the button above the right trigger) to zoom in. The screenshot below shows a zoomed-in view of Teran00bia:
The floating icons near the bottom of the screen make up Kodu’s menu. You use the left and right triggers to scroll through the menu and the A button to select a menu item.
Select the Object Tool from the menu. It’s the second menu item from the left, and its icon is Kodu, who looks sort of like a blue fish with an antenna. When you select the tool, the Kodu menu disappears and you’re now using the object tool, as shown below:
The Object Tool lets you add items to the world or edit any existing ones. There aren’t any items in the world at the moment, so let’s add one. Use the left thumbstick to move the cursor to the spot where you want to place an object, then press the A button. The following menu will appear:
This menu lists the items available to you. Starting at the top and going clockwise, the items in the menu are:
Kodu (the game system’s mascot, who can be used as either a player character or a non-player character)
Apple (useful as a health power-up, but nothing stops you from making them poisonous or explosive)
Bots 1 (a set of characters that can be used either as player characters or non-player characters)
Bots 2 (more characters that can be used either as players characters or non-player characters)
Objects (things that characters in the game can interact with, such as rocks, coins, castles and factories)
Tree (another object that characters in the game can interact with – I have no idea why trees weren’t part of the set of Objects)
Path (lets you draw paths which Kodu and the other bots can follow)
Use the left thumbstick to select Kodu from the menu, then press the A button to confirm the selection. A Kodu will appear:
You can move Kodu around by pressing the A button to select him, using the left thumbstick to pick a new location and then pressing the A button to drop him there.
What we want to do is program Kodu to move in response to the left thumbstick, as is the convention for most Xbox 360 games. While Kodu is selected, press the Y button. The screen should look like this:
Every programmable object in the Kodu game system has a set of behaviours, each one having two parts:
When, which describes the event that the object will respond to
Do, which describes what the object will do in response to the event
The behaviours are numbered starting at 1 and are listed in order of descending priority – that is, behaviour 1 has first priority, followed by behaviour 2, then behaviour 3, and so on.
Your programming “cursor” is the pencil. Move the pencil over the “+” in the “When” part of behaviour 1 and press the A button. You’ll see a menu pop up:
This menu lists the events to which Kodu can react. For now, we’re concerned with making him respond to the left thumbstick, which is part of the gamepad. Select “Gamepad” from the menu with the left thumbstick, then press the A button to confirm the selection. The menu will vanish and you’ll see that a “Gamepad” tile has been added to the “When” part of behaviour 1:
We need to specify which gamepad control Kodu should respond to. Make sure the pencil is over the “+” of the “When” part of behaviour 1, then press the A button. A menu containing various controls on the gamepad will appear:
Use the left thumbstick to select “L stick”, then press the A button. The menu will disappear and you’ll see that the “When” part of behaviour 1 has two tiles: “Gamepad” and “L Stick”:
We’ve just described an event that Kodu should respond to. Now it’s time to describe the response. Move the pencil over the “+” of the “Do” part of behaviour 1 and press the A button. A new menu will appear:
This menu lists responses to events. In this case, we want Kodu to move where the player tells him to move, which is specified by the left thumbstick. Select “Move” from the menu with the left thumbstick, then press A to confirm the selection. The menu will vanish, and you’ll see that a “Move” tile has been added to the “Do” part of behaviour 1:
We’ve now completely defined a single behaviour for Kodu: “When the player moves the left thumbstick, move in that direction”. It’s time to take our (admittedly simple) game for a spin.
Press the Back button to stop programming Kodu. You’ll now be in the Object Tool. Press the Back button again to return to Edit Mode, where Kodu’s main programming menu will become available. Use the left trigger to select Play Mode and press A to confirm the selection.
The program will start with the intro screen. Press A to dismiss the intro screen.
You’ll now be in the game world. Use the left thumbstick to move Kodu around:
Kodu moves, but he’s not so fast. Let’s look at a way to speed him up a little. Press the Back button to exit the program and return to Edit Mode. Use the triggers to select the Object Tool from the menu, then press the A button to confirm the selection.
Move the cursor under Kodu so that he’s selected:
Press the Y button to program Kodu. You’ll be return to his set of behaviours:
Move the pencil over the “+” of the “Do” part of behaviour 1, the press the A button. A menu will appear:
The menu will contain modifiers for the “Move” response. Select “Quickly” from the menu using the left thumbstick, then press the A button. The menu will disappear and you’ll see a “Quickly” tile has been added to the “Do” part of behaviour 1:
To make Kodu move even faster, you can add another “Quickly”:
…in fact, you can add up to three “Quickly” tiles to push Kodu to his maximum speed:
Play Around
I could cover more Kodu features, but you should use it the way it was meant to be used – experiment! Try adding other objects to the world and adding behaviours to them. Take a look at the programming behind the worlds that were provided with the Kodu game system (be sure to check out “Left 4 Kodu Classic”, a cute Kodu version of the zombie thriller game Left 4 Dead).
"I made the first important discovery of the 21st century: that JavaScript has good parts!"
The Software Crisis dominated the computer industry for a decade: 1960s
The crisis was that software projects were becoming too complex to manage
Projects were:
Over budget
Late
Unreliable
Not fully meeting their requirements
Unmaintainable
Failing
Insecure (this is a relatively new thing)
The software crisis isn’t over — we’re now in year 45
It never went away, we just stopped talking about it
"In other news, the sun will eventually exhaust its supply of hydrogen"
Craft vs. Engineering
Some people said that we weren’t bringing enough engineering discipline to the practice of programming
Some said programming isn’t the same thing as engineering and therefore engineering discipline doesn’t apply
Both miss the point
The real problem with software is that it’s the most complex thing we make
It requires perfection, which humans aren’t good at
It’s amazing we can make software at all
Software construction
Computer science has taught us lots of things, but not how to manage software projects
In some ways, building software is like any other sort of construction
But in some other ways, it’s quite different
You have to keep in mind that "construction" when applied to software is just a poetic metaphor
Take the case of building a wall:
It’s easy to estimate, based on the size of the wall how much time it will take, and also how far progress will be at any given time during its construction.
Try doing that with software!
Part of the problem is the nature of software
It’s both powerful and malleable
The qualities are both a blessing and a curse
One problem: The lack of metrics
There’s no objective measure of quality or completeness
We can test software, but the tests are on the same level of quality as the software being tested
Consider one of the old stand-by metrics: LOC (lines of code)
It’s not an indicator of quality
Nor is it an indicator of completeness
Another problem: Estimation is difficult
Programmers, by nature, are optimists
You have to be and optimist to do this kind of work! You wouldn’t be able if you weren’t
"I think rational people could not do programming"
As a result, we’re probably the least qualified people to do estimating
What doesn’t help is encouragement from management like "You’re a smart guy, you should be able to do it in 3 months!"
Another problem: Programmers don’t understand how they spend their time
They think they spend most of their time typing
Measurements show that most of their time is actually spent in meetings or tech conversations
(And there’s also the time spent staring at the screen going "My God, what have I done?")
As a result of this disconnect between perception and reality, programmers tend to be skeptical of process improvements that might require more keystrokes
[Story about developer who refuse to switch from a CamelCase naming scheme to a words_delimited_with_underscores naming scheme]
The programmer had an emotional attachment to the CamelCase naming scheme and argued that the underscore-based scheme slowed things down
Consider the first rule of optimization: optimize the process that is taking the most time
When it comes to programming, that process isn’t the typing!
It’s the thinking, worrying and puzzling
Programming is a social activity
Solo cases are the exception
Cost of innovation
Doing what’s been done before vs. doing what hasn’t
We’re constantly doing things we haven’t done before
That’s most likely to lead us to mistakes
Legacy
In other industries, legacy is seen as the wealth of practice and tradition, the wisdom of experience
Not ours! In software, past accomplishments are considered to be a liability
The age at which programs become "legacy" is getting younger and younger
Some programs become legacy before they’re finished\
No industry disrespects legacy the way the software industry has
It’s the best movie ever made about project management
Blandings’ problems:
Lack of knowledge of technology
Poor control over requirements
[Joey’s note: This movie’s been remade in modernized form with Tom Hanks in The Money Pit(1986) and Ice Cube in Are We Done Yet? (2007).]
Feature Cost
Development time
Deployment cost
Maintenance cost (bloat, cruft)
Download time
User confusion/training
Bug delivery
Code Value
Microview: good coding conventions
Macroview: good architecture
We need better program architecture
Architecture is hard, but conventions is easy
Think of how hospitals were improved just through simple conventions of hygiene, such as washing your hands
The simplest thing we can do to increase the value of our code is to make it readable
For example, when returning a value from a method, we should use return value, not return(value) — the latter implies that return is a function
Whatever improves human parsing of programs is helpful
Communicating
You should think of programs as a medium of intentional communication:
Communicating detailed instructions with the machine
Communicating with your development community
Communicating with yourself (and especially your future self)
Good architecture is about not collapsing into a puddle of confusion, and should enable you to change a correct program into another correct program
Cruft
It’s software scar tissue
Comes from lots of sources:
Premature optimization
Inexperience
Misread source
Feature enhancement
Death marches (which are the most avoidable source of cruft)
As cruft accumulates, complexity grows and progress slows
Eventually, the code itself becomes a source of friction
Bloat
It’s "software obesity"
In the old days, memory was expensive and you didn’t get much of it, so your programs were lean by necessity
Having only 8K – 64K of RAM in a machine put incredible constraints on what you could do
I used to dream of the day when memory would cheap and abundant enough so that we wouldn’t have to do evil things to get programs to fit
Now I wonder if maybe those constraints weren’t so bad
"Bugs hide in those rolls of fat in our programs"
Insecurity
Most programs these days have marginal security
Programs that once didn’t have security implications now do
Any bug is potentially a security bug
Good secure programming is good programming
Thinking about security might make programming easier
Refactoring
The process of code refinement, involving things like:
Correction of formatting
Insertion of documentation
Removal of cruft and bloat
Restructuring
Perhaps we should take advice from Exodus: "Plant and harvest crops for six years, but let the land rest and lie fallow during the seventh year."
Maybe do six sprints where you add new features, but on the seventh sprint, don’t add new features at all
Sometimes the best course is to start over
This is quite difficult to accept
The pain of the crash
Loss of a week’s work, a day’s work, an hour’s work, is unbearable
The illusion of completion
"It’s in the can!"
I once worked as an expert witness on conflict between 2 game companies
The original game company had split up; the new company was being sued for plagiarizing the original company’s game engine
I reviewed both game engines and determined that the new game company had written a whole new engine in 2 month — they’d learned for the experiences writing an engine for the old company
The owner of the old company couldn’t accept that; he thought the value of the codebase was 100 man-years, not 1
An experienced team can redo what they just created quickly. The team’s focus must be on simplicity to avoid second system effect
Have regular code readings
Don’t wait until release to do code reviews
Do team code reading regularly during development
Problems can be discovered early
Good techniques can be shared early
Experienced developers can lead by example; novice developers learn from the group
They should be: frequent, helpful and respectful
You need a healthy team – a dysfunctional one will tear itself apart
Conclusion
Quality first. Quality last.
Readable code. Code reading.
Invest in the quality of your code base.
Invest in your programmers and managers.
Quality is the most important feature.
If you look at all the polished, completed code you write at the end of a year, you could type it all in a day
Typing is not what we do; it’s thinking and communicating
You young’uns may have learned about typefaces and the difference between serif and sans serif from using the “font” settings on your computers, but I learned from using Letraset (and often, its budget-priced brother, Geotype). They were sheets of rub-down transfer lettering and clip art. The principle behind Letraset wasn’t all that different from temporary tattoos. The stuff went the way of the dodo once desktop publishing and laser, inkjet and dye sublimation printers caught on.
Every now and again, I make it a point to pick up some reading material on a field or industry that’s completely unrelated to my own. I find that it both satisfies my curiosity and helps me see things from a completely different perspective. In one particular case, when I found a copy of Sheep Canadalying abandoned on a subway seat, I enjoyed the puzzled and concerned looks from the other passengers as I read the magazine. Not only did I get a little entertainment, but I learned a little bit about what goes into making the lamb chops and sweaters I love.
I also like asking people questions about their work, especially if it’s in field different from my own. It probably stems from the fact that everyone in my immediate family is in medicine; I’m the “black sheep” who went into computer programming. I often chat with my wife and her co-workers at the University of Toronto’s Mark S. Bonham Centre for Sexual Diversity Studies (a fascinating line of work, by the bye), my father-in-law about that branch of the insurance industry that concerns itself with executive benefits, friends who work in the television and movie industries, and so on. I love hearing their stories and find that seeing their perspectives broadens my own.
I’ve even taken on little non-developer side jobs just to get a different perspective. I’ve moved an entire warehouse of high-end dresses, had a fair bit of success as a street musician, gotten ink-stained at an old school print shop and even had a stint as an accordion-playing go-go dancer at a Toronto nightclub.
You Go Hither and I’ll Go Thither
It’s this “wanderlust of the mind” that probably led me, a guy who was actually quite happy in the “develop on the Mac, deploy on Linux” world, to becoming a Developer Evangelist with Microsoft. Each world has its own history, culture, customer base and approach to technology, and each offers lessons to the other. As I’ve said before, technology is a great big smorgasbord, where there are enough seats and dishes for everyone and every taste. Wouldn’t it be a waste if you stuck only with the dishes you knew?
I’ve spent the last year getting reacquainted with the Microsoft development world, and it’s different in many ways. There’s the obvious stuff such as operating systems, programming languages and tools. There’s also the more subtle stuff: conference demographics and what people do in the hallways at conference, the sort of apps that get written, what people do in their spare time and so on.
Don Dodge is experiencing the same thing…just in reverse. Just as I’ve gone from being a Mac guy to running Windows 7 as my primary operating system, he’s crossed over from Windows to the Mac OS and writing about his experiences with the transition in an article titled From MSFT Evangelist to Mac Enthusiast – The Other Side of the Road.
There are some lessons to be learned from Don’s observations, a fact that wasn’t lost on Todd Bishop. In his article on Don’s “switching” experience, he writes:
This sentence, in particular, caught my attention: "After years of defending Microsoft against the Apple fanatics I decided to go to the other side of the road to see for myself," Dodge writes.
Good for him, but the fact that he hadn’t seen the other side of the road as a Microsoft employee is a symptom of a larger problem at the Redmond company. Loyalty to and appreciation for your own products is nice, to a point, but after interacting with people at Microsoft for the better part of the past decade, I’ve never quite understood, logically, why it’s taboo for its employees to use competing products.
…
…think what would happen if Microsoft employees experienced and saw around them, every day, a true reflection of the competitive landscape — including Microsoft products and rival technologies. My hunch is that they’d come away with a better understanding of what motivates specific consumer actions, and how they might be able to get consumers to pick Microsoft products instead.
Todd, you took the words right out of my mouth. It’s right along the lines of my own philosophy, which I wrote about in the article Evangelist, Immigrant and Shaman:
What Microsoft needs badly is a shaman. They need somebody who is situated physically within their culture, but outside it spiritually. This isn’t a person who hates Microsoft, but it’s a person who can actually see it.I can do this for you. Give me a hut in your parking lot. I will eat mushrooms, roll around in your cafeteria, and tell you the Goddamned truth.
It’s the style in which I do my work. Yes, I devote a lot of time and effort to Microsoft’s tools and technologies, but I make sure that they’re not the only things I look at. I try to keep abreast of things like the IDE conventions in XCode, what’s happening in the worlds of the iPhone and Android, non-Microsoft languages and frameworks such as PHP, Python and Django, Ruby and Rails, templating systems like HAML and Sass and the NoSQL movement. Each has lessons (the Microsoft term is “learnings”, which I refuse to use, since I consider it a non-word) that can be incorporated into the Microsoft world, just as I’m sure that we too have lessons to offer to these other worlds. And in the end, we’ll all get better tools and technologies for our work, life and play.
It’s something you should try as well. Try using some tool or technology that you wouldn’t normally use. Hang out with developers from “the other side”. Pick up a copy of Sheep Canada. Broaden your perspective and see what you’ll learn!
