Signs on the Sand

Seems like my wife has found the hobby of her life. She's all about photography now. Books, sites, forums. She's overgrown our little but powerful Canon S70 and got new shiny (not really shiny, but a black one) Canon 400D (aka XTi). S70 is finally mine again!

Here are some her first pictures taken with Canon EF 50mm f1.4 Lens:

Tel-Aviv view from Old Jaffa:

Sunset in Old Jaffa:

Couple of shots taken in a nice place called Herzliya Marina, this is just 1 mile away from my work.

"Going underwater":

 "Going home":

John Lam ported Textmate's Vibrant Ink theme to Visual Studio. Get it here.

Awesome. Note that toolbar buttons are nowhere to be seen. I noticed that while I'm only barely use toolbar, it still takes lots of space and more irritating - distracts attention like xmas tree and tends to rearrange itself I have no idea why. Besides turning toolbar off is the best way to learn keyboard shortcuts and once you do so you never look back.  While you at it, here is a nice Visual Studio .NET 2005 Keyboard Shortcuts poster from Jeff Atwood.

I'm a big fan of such kind of color themes. So far I was using Scott Hanselman's Visual Studio 2005 Font and Color Settings, but now I feel that's not eXtreme enough for me.

Btw, Windows Zune Theme is perfect match for Vibrant Ink theme. Try them out.

Update: check out also cool Moria color scheme port for Visual Studio by Tomas Restrepo (see comments).

Victor Garcia Aprea, the guy behind VSSDK Assist writes about his experience and vision of extending Visual Studio.

My Love / Hate relationship with Visual Studio:

Visual Studio is a tool I love to use.

Visual Studio is a tool I hate to extend.

Enough said. Ditto.

In another post, Dreaming of a huge Visual Studio Community, Victor says basically he's very pessimistic about Visual Studio community:

What is the hardcore way of extending Visual Studio: VSIP.

And what are the first things that come to mind when you think of “VSIP”: expensive and obscure. Expensive because it used to be 10k/year and obscure because its COM roots and it’s very poor (close to inexistent) documentation.

You tell me how do you build a huge community around expensive and obscure? You just simple can’t. I believe the past years were more than enough to prove this.

Can you build a community around VSX? Although this is surely an improvement over expensive and obscure, IMO, this is still not enough.

Why?

Because all of the “obscure” it’s still there. Because you still need to mess with COM interfaces all the time and the versioning craziness like “IVsComponentEnumeratorFactory3” and native structures and enumerations that were coded when naming like “__VSMEPROPID2. VSMEPROPID_LAST2” made any sense. Let alone the VBisms you can find in today’s DTE automation layer (like indexes starting at 1 instead of 0, etc). Also, I don’t want 45 different and incompatible ways of doing the same thing.

Well, again, I feel the same way. While VSIP is free now, I believe Microsoft already missed the chance to make Visual Studio the development platform of choice for masses. Think about it - when Eclipse didn't exist yet, Microsoft already had fully extensible rich Visual Studio platform, but they were stupid enough to make it fully closed, very complex and stunningly expensive. No wonder everybody loves extending Eclipse platform and even gurus hate extending Visual Studio.

Microsoft XML Team posted a series of screencasts unveiling some new features in Visual Studio Orcas 2008. Short ones, but to the point, without blablahblah. I particularly like XML Editor ability to generate stub XML document from XML schema in just one tab click. Oh, and XSLT debugging is getting better and better. Data breakpoints is a great feature.

Ok, done with sweet part. Black hat on. XSLT debugger still must be run using separate obscure button, called "Debug XSLT", which even has no keyboard shortcut. Hitting F5 will obviously start debugging C# or whatever actual project is. That sucks.

Every debugging menu item works for XSLT debugger, except well, "Start Debugger". I made this mistake zillion times - working on XSLT, want to debug, hit F5, getting C# debugger. Oh, wait, no I meant this button, where is it? That's wasted time. But come on, you are in C# project, that's why F5 starts C# debugger.

My solution to the problem is dedicated XSLT project type for Visual Studio I'm building in the IronXSLT. Separating is good here. The whole project is XSLT-centric, including of course F5 button. In XSLT project F5 will naturally start XSLT debugger.

Another painful point. Derek says his favorite XML Editor feature is "Go to definition":

One of my favorite 'hidden' features is goto-definition. Position the cursor on an element in a document with an associated schema, and F12 will jump you to the part of the schema that governs that element. I occasionally get some very complex customer schemas. F12 can also be used to navigate with-in a schema, from an element declaration to the declaration of it's type, or to the base type declaration. When the schema spans megabytes and multiple files, this is invaluable.

Call me a freak, but I hate "Go to definition" feature in Visual Studio XML Editor. Not because I think going to the definition is bad idea, but because it fools me too many times. It's useful feature when editing XML, but terrible joke when editing XSLT. And 80% of time spent in XML Editor I'm editing XSLT. Huge XSLT stylesheet, call to some template: <xsl:call-template name="go-find-me-template"/>. I want to see the template. Click on "go-find-me-template", F12 - Boom - XSD definition for xsl:template element. That sucks.

I mean it's not fully done. XSLT Editor must override "Go to definition" command and provide meaningful implementation. Currently it's wrong. Nobody wants to see XSD schema for XSLT. It's like when hitting F12 on a variable in C# code being shown C# grammar rule.

Again, I'm going to fix it in the IronXSLT. Not sure if I can override default "Go to definition" command, but at least I can provide my own, which will actually be useful in XSLT.

Craig Skibo of Microsoft writes about new thing they announced recently - Visual Studio Shell. What the hell is that? Marketing description is unreadable:

A streamlined Visual Studio development environment, the Visual Studio Shell provides the core foundation so you can focus on building your application’s unique features.

But Craig gives a description mortals like me can understand:

Over the years many people have been creating packages and Add-ins for Visual Studio, but if anybody wanted to use your package, they had to have a copy of Visual Studio (pro or above) installed on their computer or you had to license what we called the PPE (or “Premier Partner Edition” – another beautiful name) and it was not exactly cheap.

What I have been working on is allowing you to, by building a small exe program and editing an even smaller text file that looks like a .reg file, create your own application which consumes the Visual Studio shell. Your program is branded with your company name and logos in any way that you wish, the only place that any Microsoft logo appears is on the splash screen where on the bottom right we put the text “Powered By Visual Studio”. And best of all – it is free!!! You can also distribute the PPE version of Visual Studio Shell, for free!!!

Ok, so Visual Studio Shell looks like Microsoft answer to the Eclipse Platform.

That's a good move, but what bother me tough is the fact that building plugins for Visual Studio is still a nightmare compared to building Eclipse plugins. If Microsoft wants to achieve at least a portion of adoption Eclipse platform has they have to simplify Visual Studio SDK programming substantially. Which is hardly possible without substantial redesign/rewrite of this 10 years old monster.

Visual Studio Hawaii (next after Orcas) was supposed to be such new dramatically redesigned version. And this announcement sounds like a sign of a major Visual Studio redesign going on right now.