Type t = typeof(int);

switch (t) {
   case typeof(int):
      Console.WriteLine("int!");
      break;
   case typeof(string):
      Console.WriteLine("string!");
      break;
   default:
      Console.WriteLine("unknown!");
      break;
}

Doesn’t work, right?  Throws ‘A value of an integral type expected’.  This is because C# switch statement is picky when it evaluates the cases. It wants static values and can’t get fancy with object comparisons.  Switch statements aren’t just a bunch of if/else statements when boiled down to IL.  There is more detail in this StackOverflow question.

So we’re out of luck, right?  Not so fast.  Let’s think about what we want: behavior associated with a .NET type.  How can we accomplish that?  I got an idea from Judah’s answer to the aforementioned SO question.  Judah uses a generic dictionary to associate the actual type, as the key, with a string.   Interesting.  Why not associate behavior with those types instead?  With delegates like Action<T> and Func<T>, we can do that.

Here is Judah’s answer refactored to use a generic dictionary:

Type someType = typeof(int);

Dictionary<Type, Func<string>> typeTable = new Dictionary<Type, Func<string>>();
typeTable.Add(typeof(string), () => { return "It's a string!"; });
typeTable.Add(typeof(int), () => { return "It's an int!"; });

Console.Write(typeTable[someType].Invoke());

Now we can call any of a number of associated delegates based on a Type object. We can get even fancier if we want, using Action<T> if we don’t need a return value or Func<T, TResult> if we want to pass parameters into the behavior. We get the usual performance hit of using delegates, but unless you’re guiding a missile in real time I don’t think it’s a dealbreaker.

I’ve used this technique and it works great for me, hope you find it useful as well.

My “productive” time starts at about 6am and ends, on a good day, around 6pm.  On a very good day, caffeine can extend that time into the evening.  I know this schedule is grounds for revocation of my geek card, but I’m a husband and dad with three kids, so my schedule is largely theirs.  Outside my productive time, my brain slowly descends into guacamole.  The frontal lobes turn to runny eggs and I can’t focus on code anymore.

This means that I have about eight good hours a day to devote to work, be it my own or otherwise.  Eight hours sounds like a lot, but when you count drive time, boot time (our login scripts are glacial,) lunch, and body breaks, it rounds out to more like six.  I try to game the system by working from home when I can (no drive time) and eating at my desk, but it’s still less than eight hours.

Six hours per day isn’t a lot.  I have to squeeze every possible moment out of those six hours in order to accomplish anything meaningful from one day to the next.  This means staying as focused as possible on the tasks that will truly make things happen.  I’ve recently noticed a major productivity killer: metawork.

Metawork is what we do to convince ourselves we’re doing something useful when we’re actually slacking off.  When our brains seize up and our focus is off, we turn to metawork to look and feel busy.  Examples of metawork include:

• Updating to-do lists
• Writing pseudocode
• Tweeting/Talking about writing code
• Meetings
• Reading about technology that has nothing to do with anything you’re working on
• Answering random StackOverflow questions
• Reading blog posts (D’oh!)
• Writing a blog post (Double D’oh!)

This is an incomplete list and will probably apply differently to different people.  Some people are paid to blog, so that wouldn’t be metawork for those people.  I’m not paid to blog, so I’m currently burning valuable time.

Back to it!

MVC Melee is coming June 18-20.  Inspired by Rails Rumble, MVC Melee is a 48-hour competition in which the ASP.NET MVC men and women will be separated from the metaphorical boys and girls.  Read their FAQ and Rules for details.

I’ve been having a ton of fun with ASP.NET MVC for about a year now, and I’m just starting to feel like I really “get” how it works.  Now that I do, I’m never looking back to webforms.  MVC (and it’s bigger, better cousin MVVM) just makes more sense, though it was quite a new way of thinking to really grok it.

I’m going to be sharing some of my most recent work with ASP.NET MVC.  Watch this space for that soon, and let me know if you’re interested in forming up a team for MVC Melee!

What it Does

VSTime is a simple little Visual Studio plugin that records events such as file opening, compiling, and debugging. It tallies up all that time spent doing those individual things and presents a report. You can see how much time you spent editing files, building, and debugging, and a total time spent on a solution.

I hope that this utility will be useful to developers in measuring the time you spend actually doing the rubber-to-road work of development. I hope no pointy-haired managers get it in their heads that this tool can or should be used to measure productivity. It can’t and won’t, so don’t try.

However, if your pointy-haired manager insists that a 386 with 256MB of RAM should be plenty, don’t be shy about showing him/her how most of your time is spent building/compiling your projects. Graphs like the one in VSTime could be very effective that way!

Design

I agonized over some of the design decisions, most especially the method for persisting the event records. I finally settled on SQL Server 2005 Express for two primary reasons:

1. If you have Visual Studio 2008 installed, SQL Server 2005 Express is installed by default.
2. The row_number function in SQL 2005 makes tallying the time of each event rather easy.

VSTime is designed in a way that should make it easy to plug in a different persistence layer. I may develop a SQL Compact or SQLite-based DAL plugin in the future.

VSTime takes advantage of the EnvDTE.DTE interface, which is the wrapped COM interface that represents the Visual Studio IDE automation object model. EnvDTE.DTE exposes an Events interface, which in turn exposes a bundle of interesting events, including Solution, Window, Build, and Debug -related events.

How It Works

Each of the events, including file open, build, debug, and a few others, is recorded to an EventRecord table. The duration of an event is the time it occurs to the time the next event is recorded. So, for example, if a file is opened at 12:00.00 and then the project is built at 12:05.00, then that file has been “active” for five minutes. The action of the next event “ends” the current event. If the user then goes back to the file, the WindowActivated event is registered and time begins to accrue on that file again.

If you walk away from your desk for a break, an idle counter kicks off after five minutes of no activity. This records an IDLE event, and the duration of IDLE events are filtered out in the reporting. If you are editing a file, a keyboard event resets the counter each time you hit the Enter key. The idle timer is hardcoded at the moment. I have set up a work item to make it configurable.

You can view the time spent on the currently-opened solution by selecting Tools-VSTime. Like the little stopwatch in the menu? It’s the extent of my artistic ability

The first tab of the VSTime ToolWindow displays a grid of the time spent on each activity, in descending order. Based on my experience, you will likely find a file or two (or more) at the top that contains all the important stuff, with lesser files, debugging, and building further down. This of course will depend on your usage patterns and the nature of your projects.

The second tab displays a horizontal graph of all the events. You can zoom in on the events by drag-selecting an area of the graph. Zoom back out by clicking the little button above the scrollbar.

Data

The VSTime database is very simple. There are two tables: Solution and EventRecord. Each EventRecord relates to a Solution. As explained above, Event duration is defined as the moment an event occurs to the to moment of the subsequent event. I believe this is effective, but there are some issues.

The primary issue to be aware of is that it is possible to edit a file while debugging in Visual Studio. This means that you could be, in practical terms, “Debugging” and editing a file at the same time. The Solution Total Time will still be accurate, because the act of activating a file window will “end” the debugging event. However, VSTime does not currently support the idea of concurrent events, so your event time tallies for Debugging may be off if you often edit files while debugging.

Future Development

Support for VS 2010 is planned and will be in the next release. I don’t think I’ll be spending any time on VS 2005 compatibility, but if there is tons of interest I may reconsider. Future releases will include more tests. I’m also looking into the possiblity of tracking additional interesting events such as source control commits.

Yes, It’s Open Source

Please try out VSTime if you think you’ll find it useful. If you love it/like it/hate it, don’t be shy. Post here or on Codeplex. Tell the world what you like/hate about it. If you’re really passionate about it either way, get involved and make suggestions or even post a patch!

SELECT SolutionID, EventName, EventDuration
FROM Events

I needed this:

SELECT SolutionID, EventName, SUM(EventDuration) EventTotal
FROM Events
GROUP BY SolutionID, EventName

Here’s the LINQ:

var events = from e in summary
   group e by new { e.SolutionID, e.EventDetail } into g
   let TotalMinutes = g.Sum(x => x.EventDuration)
   orderby TotalMinutes descending
   select new EventSummary
     {
          SolutionID = g.Key.SolutionID,
          Name = g.Key.EventDetail,
          Seconds = TotalMinutes,
          Minutes = TotalMinutes / 60.0,
          Hours = (TotalMinutes / 60.0) / 60.0
     };

The magic is in line 2:

   group e by new { e.SolutionID, e.EventDetail } into g

You can group by as many columns as you need with that little nugget. Using the anonymous type feature in C# 3.0 you can group on as many columns as you need. Enjoy!

In a nutshell, RIA applications are client apps that are delivered over the web. They run in a sandboxed runtime environment on the client, and get their data mostly through services hosted in the cloud. So what’s the big deal?

The runtime is the big deal. With a sandboxed runtime environment, you get a few things for free. Most important among these is security and cross-platform compatibility. Whether it’s an AIR or Sliverlight applicaiton, it will (theoretically) run anywhere the environment is installed. No worrying about HTML/CSS formatting or quirky browser implementations- if the environment is there, it runs. You also get the speed benefit of moving processing back to the client. No more waiting for IIS/Apache to process your request- RIA apps run locally. As a developer you also get the rich UX capabilites, which could be the most important aspect of any application.

So why are Microsoft and Adobe beating a path to developers’ doors? Why do they care about RIA? Here’s a tweet from Jeff Atwood:

“When everything is a web app, maybe we’ll have new operating systems…”

This simple, casual comment sums it up. Eventually, just about every application will be delivered over the web. Sticking in a CD or downloading an installer is just so 2005. The winner(s) in the RIA platform space will offer to developers a potential audience of millions of users, regardless of OS. All this with practically free delivery over the web. That’s a big deal.

As the move to RIA continues, “web application development” will mean less HTML and more XAML/MXML. Browser compatibility will be less of a concern. Web developers will rely on the platforms to handle runtime compatibility while they focus on application development (as it should be!) A single codebase targeted to a RIA platform can support a potentially huge audience, making development cheaper and reducing testing cycles.

RIA is still in its infancy. So far I see way more potential than real applications, though that’s changing fast. I think Adobe’s AIR is currently beating Silverlight for features overall, but I see that gap closing with each release of Silverlight. Over time, I see both platforms effective across just about every major market OS, including mobile. As Adobe and Microsoft figure out how loose they can safely make the sandbox, more powerful features will be offered.

Eventually, I see a time when users spend more total minutes interacting with RIA applications than they do their OS. I see fully-featured RIA “desktop replacements.” Imagine booting up any old OS, visiting a website, and getting a completely different experience wherever you are. Store your data in the cloud, run a RIA OS, and the local OS suddenly doesn’t matter so much. Call it a “Virtual OS” or a “Cloud OS” or whatever you like, it’s coming fast.

The one thing I can say for sure is this: no one can say with certainty what RIA will mean over the long term, but it smells to me like opportunity. Shifts like this come maybe once a decade. It’s not often you can see the swell of a new meme ahead of its crest. Getting into RIA development is easy and getting easier, so jump in! The water’s great!

Windows 7 has been a joy to use overall. The entire install on my Dell D830 took less than 30 minutes. That’s an estimate, I didn’t time it because I was too impatient! I can say the 64-bit version fairly screams. I have a 7200RPM hard drive and 4GB RAM on this machine, so it’s well powered. I can honestly say this is the most responsive OS I have ever used. Startup and shutdown are insanely fast. I don’t remember ever waiting for the system to grind, which has been wonderful for my productivity. I run VS.NET, SQL Management Studio, Gimp, IE, and many other apps simultaneously and it’s smooth as silk.

When I started making plans to run Win7, I didn’t know my laptop was 64-bit ([blush] I’ve been on the developer side so long my hardware chops have atrophied!) Windows 7 64-bit has none of the hardware compatibility problems that plagued XP 64-bit and even Vista. I run XP x86 on the same machine by day, so I can compare the difference in performance. Wow. I’m sure there are many others like me out there running a 32-bit OS on 64-bit hardware. If that’s you, UPGRADE. You’re running a Ferrari on two cylinders. It’s the cheapest performance upgrade you’ll get in a long time.

I learned several things at the launch event today that I didn’t know before.

Hardware Target

The first presenter at the launch event explained that Windows 7 is the first OS in Microsoft’s history that is targeted to run fast, not just acceptably, on older, slower hardware than its predecessor. He cited the popularity of netbooks and the “breakdown of Moore’s law” as the thinking behind this targeting. I don’t have much experience with Vista, but I can say from personal experience that the boot time for Windows 7 is good if not great when compared to XP, and shutdown is almost like a lightswitch. Apparently the improved startup time is due partly to parallel loading of drivers, where possible.

Problem Step Recorder

This is a support dream. It’s simple: have your end-user (mom, dad, grandma) go to Start and type “PSR” in the search box. The Problem Step Recorder will appear in the list. Have your end-user hit record, then follow the set of steps that led to the error about which they’re bugging you. Hit stop, then save the file, which is a ZIP file. They email you the file, and you see a wonderful stream of screenshots with detailed information about the system state, all in your browser. Cool stuff.

Shake

I knew about the ease of side-by-side windows: just drag a window all the way to the right or left and it will pop to that side. I didn’t know about shake, though. Grab the window bar and give it a shake. All other windows will minimize. Shake again and they restore. Neat.

Powershell UI

Powershell 2.0 is now baked right in, and has a cool little editor. I haven’t dug into Powershell very much yet but it looks very cool for automating tasks.

Windows API Codepack

During the developer demo, the presenter introduced the Windows API Codepack. This is a managed wrapper around the native API bits that make Windows 7 sing. We saw demos on Jump Lists, Icon Overlays, and Trigger-Start Services. Very little code was required to make these things work. If you’re migrating an application to Windows 7 the CodePack is the place to start. You may also want to check out the Photoview uber-demo.

Libraries

I was actually surprised that I had been looking at them in Explorer since installing Windows 7 but never really noticed them. Now that I know what they are I like them a lot. It’s simple: Libraries are collections of folders. There is an API for creating and manipulating them, though you will want to be careful changing something that is really a user-preference system.

Windows 7 Troubleshooter Packs

This is more cool stuff for reducing those pesky support costs. The presenter demoed an issue where there was no sound coming from his laptop. He ran the Audio Troubleshooter, and it unmuted his audio for him. You can write your own packs, which are simply collections of Powershell scripts held together with an XML manifest. You can pack them into a singed CAB file and distribute them with application installers or over the web. I found a great crash course here.

This is just a few of the cool things in Windows 7. For more, take a look at Direct Access, XP Mode, and BitLocker. All in all, Windows 7 looks like a win for Microsoft. I’ve enjoyed it personally and it looks compelling for businesses, which is a big improvement over Vista. It’s in stores and shipping from vendors October 22nd. Check it out!

Not Invented Here (NIH) happens for a variety of reasons. Those that follow NIH are loath to incorporate any ideas from outside their own team (and sometimes their own heads.) It’s a sort of mental ossification that occurs when a developer is unable to value contributions from outside. This may manifest as a reluctance to incorporate open source code into a project. NIH adherents tend to distrust frameworks developed by other companies or developers.  At its worst, NIH folks won’t even accept contributions from other team members.

It is understandable why developers might prefer their own code and methods over those written by another. Codebase familiarity is comfortable and fast. New methods take time to learn and really incorporate, and we don’t always have the time or management blessings to climb new learning curves on the company nickel. We rarely get paid extra to write good, reliable software (there’s a whole other can of worms!)

It’s important to fight the urge to stick to your comfort zone. As developers, our value comes not from what we know, but what we can learn and how quickly we incorporate new information. Imagine trying to write an entire application without an Internet connection. The most competent developers still need to research and look up syntax now and again. It’s important to go beyond simple task-focused research. Challenge yourself to the core! Ask tough questions about why you do things the way you do them. Try new things. You can’t expect to maintain good professional bona fides while working in a bubble. New ideas are essential to any developer’s continuing education.

Avoiding NIH will also help you avoid RTW: Reinventing the Wheel. If you decide to build the biggest baddest new blogging system (for example), first ask yourself why you think yours will be better than the other million open source blogging systems out there. If you have a good answer, go for it! However, even if you think you have a totally new concept filled with win, do yourself a favor and evaluate the other systems. You’ll learn a TON.

There is a caveat here: don’t go looking for nails every time you find a shiny new hammer. Tools are just that: tools. You can build something great or smash your (or your clients!) thumb. Evaluate each newfangled thingie, whether it’s TDD, IoC Containers, Mocking, frameworks, or whatever, with a critical eye. Take some time to try it out. With a little practice, the really compelling stuff will feel like an old shoe that you’ve worn for years. Let the stuff that doesn’t sing for you just fall away.  It’s extra effort, but it’s totally worth it.

Exception Details: System.Security.SecurityException: Request for the permission of type ‘System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′ failed.

After much Googling, discovered this:

Prologue: There is a really cool demo of Silverlight capabilities here.

What is Silverlight?

Remember “Write Once, Run Anywhere?” This lofty goal has been promised before <cough Java cough>. It’s still a desirable thing, to be sure: just ask any developer that still has to code webpages to look decent on IE6.

A new generation of technologies is beginning to deliver on the multi-platform promise of old. Silverlight is Microsoft’s entry into that fray. The Silverlight runtime is a subset of the .NET Base Class Library, runs on PC and Mac, and runs in all the major browsers including IE, Firefox, Safari, Opera, Chrome, and more.

Silverlight was born as “WPF/E”, which stands for Windows Presentation Foundation/Everywhere. WPF and Silverlight are both Microsoft’s latest User Interface technology offerings. Both are based on eXtensible Application Markup Language, aka XAML. The difference between WPF and Silverlight is in delivery: WPF is a desktop technology. Silverlight is a Rich Internet Application framework for delivery of rich user interfaces via the web.

No discussion of Silverlight is complete without mentioning Flash. Yes, Silverlight competes with Flash. Directly.

1. Both Flash and Silverlight run in a sandboxed environment on the client.
2. Both offer vector graphics and media (audio/video) capability.
3. As of Silverlight 3.0, both support an out-of-browser running mode (Adobe AIR allows Flash/Flex programs to run locally outside a browser.)

The primary difference between them is that Flash uses Actionscript, and Silverlight is based on .NET, which means Silverlight applications may be developed in any .NET-compliant language. These include VB.NET, C#, and with the Dynamic Languages support in Silverlight, IronPython and IronRuby.

Browser Integration

A Silverlight application may be embedded into a webpage using the Silverlight ActiveX control and the <object> notation, or by using javascript. A javascript bridge (HTML Bridge) between Silverlight applications and the hosting page allows javascript to call into the Silverlight app, and managed Silverlight code to call out to javascript functions declared in the hosting page.

XAML

XAML stands for eXtensible Application Markup Language. It is an XML-based language for describing visual elements of a User Interface.

Think back to the days of VB6: the UI was all tangled up in the code. Then came .NET, and for some time the UI was all tangled up in auto-generated “designer” code. Now comes WPF, Silverlight, and XAML. Using XAML, the UI definition is completely separated from the programming logic. XAML pages declaratively describe an object graph. Parsing a Silverlight XAML page results in the instantiation of that graph and the rendering of the user interface it describes.

Dynamic Language Support

Dynamic Languages in Silverlight allow IronPython and IronRuby programs to manipulate and interact with the user interface in the same way as C# or VB.NET. This opens up Silverlight to Python and Ruby developers. The DLR Console Sample demonstrates another capability: interacting with a running Silverlight application in real time using code.

Layout System

The Silverlight layout system determines how visible elements of an application are positioned relative to the application host and each other. Several layout controls are included with Silverlight, including Canvas, Grid, and StackPanel, to name a few.

Controls are laid out by the engine using inherited Measure and Arrange methods that cooperate to determine how much visible area a control wants, and how much it gets as a result of the overall layout of all visible elements.

Controls

Silverlight 2.0 introduced a library of ready-made controls, such as TextBlock, TextBox, ComboBox, etc. MSDN has a handy directory of controls.

Silverlight controls are “look-less” in that the code that defines their behavior contains absolutely nothing about how they appear visually. The visual appearance of controls, including custom controls, is defined entirely in XAML. The .NET class that implements the control is referred to as a “control contract.”

Just as with .NET Winforms and ASP.NET controls, WPF/Silverlight controls can be customized or created from scratch. Customization of controls in Silverlight is quite different, however. Winforms and ASP.NET controls can be subclassed and then customized. Silverlight control customization involves replacing the ControlTemplate of a control. This allows a developer to completely replace the visual behavior of an existing control.

Common content may be shared across controls using a DataTemplate. This supports adding a common icon to a custom “submit” button, for example.

Networking

Communicating with the cloud in Silverlight presents several security challenges. Silverlight applications cannot freely communicate with just any service over any port; there are restrictions to prevent security threats such as malware, viruses, and spyware. Depending on configuration, communication is either handled for the Silverlight application by the browser, or the Silverlight client itself handles HTTP/HTTPS communications. The latter configuration is useful for RESTful communications or when the developer wants to handle cookies manually.

The standard class for network communcation is WebClient. WebClient has asynchronous methods for writing and reading to a network stream. The HttpWebRequest and HttpWebResponse classes contain methods for more granular communications, including the ability to manipulate HTTP headers. Silverlight also supports Sockets for low-level TCP communications.

The security model Silverlight uses allows minimally-restricted communication between the hosting domain and a Silverlight application. If a Silverlight app wants resources (i.e. files, read/write to a service) from another domain, however, a cross-domain policy file must be present on that domain. Flash/Flex/AIR applications use a similar security model, and Silverlight can read Flash cross-domain policy files. The policy file is an XML-formatted file that indicates what services and resources are accessible, and to whom.

Data

This was a source of confusion for me when I first started with Silveright. It’s important to remember that Silverlight apps run in the browser. This makes them more like Winforms apps than ASP.NET apps. Silverlight apps get their data over the wire just like any other desktop application. What does a Winforms app do when it needs data from the cloud? It uses a webservice.

Silverlight apps can get their data over the wire via RESTful or SOAP-based services like WCF. Microsoft provides some help for data access in the form of ADO.NET Data Services (formerly Astoria) and .NET RIA Services.

Here I am going to punt and guide you to the best authority I’ve seen on the difference between these options: Shawn Wildermuth.

Media and Animation

Silverlight’s Animation system is centered on the Storyboard control and the Animation controls. “From-To” animations including DoubleAnimation, PointAnimation, and ColorAnimation are used to animate double, point, and color-type properties of a control. These animations have keyframe-based companions (DoubleAnimationUsingKeyFrames, PointAnimationUsingKeyframes, you get the idea) that use keyframing to perform the animation. Keyframing is a technique by which frames are interpolated between key points that are set in an animation.

Bonus: DependencyObject and DependencyProperty

DependencyObjects and DependencyProperties were not in the mind map, but they are important enough that they probably should have been, so I’ll go into them briefly here.

Silverlight controls need lots of dependencies on each other for things like animation and layout. This requires more than the common model of using private fields to back public properties. DependencyProperties are like super-properties. When the values of a DependencyProperty are getted (is that a word?) or setted (again?) the internal implementation of DependencyObject (DependencyProperties’ base class) allows other things to happen, like notifying an ObservableCollection that a member has been updated (this is databinding), or animating a property of a control from outside the scope of that control.


]]> http://daveswersky.com/2009/09/29/silverlight-research-summary/feed/ 0 daveswersky