Obviously May is the best month of the year. Here in Moscow it is not usually very hot, although at the moment it's 27 °C (~80 °F). However, it is always warm enough to wear T-shirt and have a walk across the city to admire its beautiful sights. May seems to be the most attractive month to visit Moscow indeed - winter or autumn will meet you with lowering sky, and summer is too sultry and dusty to enjoy the trip. Late spring is optimal.

I love Moscow! This city combines very old architecture and modern offices, beautiful Orthodox churches and massive buildings of the Stalin epoch. So - let's have a short walk across the city (mostly central part) and make sure it is magnificent indeed. I hope my comments below won't distract you too much :)

By tradition, let's start with the heart of the city - Kremlin. The big tower is named Spasskaya. The small tower nearby is named Tsarskaya because tsar Ivan IV liked to observe from it what was happening on the Red Square. Last time I was inside Kremlin being a child so no photos with the President today, sorry :)

Another view of Kremlin (from an enbankment).

St. Basil's Cathedral. Legend says that Ivan IV had the architect, Postnik Yakovlev, blinded to prevent him from building a more magnificent building for anyone else. What luck living several centuries later!

Russian policemen armed with the latest modification of Kalashnikov halberd. The halberds are used to execute criminals trying to penetrate into the State Historical Museum (on the background). At least I believe it might be that way several hundred years ago.

A pigeon attacking Marshal Zhukov's horse. The horse looks surprised.

A developer taking a rest after many hours of debugging (he does not adopt unit testing).

No comments (just another Moscow sight).

Alexander Garden, the entry.

The Tomb of Unknown Soldier in Alexander Garden. The guard stands without movement for hours. I envy his tenacity - there are so many pretty girls strolling by...

Tulips in Alexander Garden. I recall a day when I presented my wife with a bunch of 101 tulips... No, I didn't steal them from this flower-bed. It was winter actually :)

The Cathedral of Christ the Saviour. This is the largest Eastern Orthodox church in the world. It was demolished by communists and restored in 90s.

That is how the Cathedral looks like at evening. This photo was taken by my wife - I had nothing to say but "wow".

A monument to Alexander II, the Emperor of Russian Empire.

A kitty guarding Alexander.

96-meter-tall Peter the Great statue on the Moskva River bank. It is apparently supposed to scare off pirates if they ever appear on the river. We are thankful to Zurab Tsereteli (the sculptor) that he didn't make the ship proportional to Peter.

A rainbow caused by fountain's splashes.

Moscow is full of beautiful churches. I have an idea of collecting photos of all the churches in the city... alas, due to the lack of time this idea seems impossible to implement.

A funky cabrio :)

Aspose Moscow Office, under intense development. Yeah, just a branch. What? Oh... I was just told this is actually Moscow-City, the International Business Center... It is so easy to confuse...

Ostankino TV Tower. Being 540 metres (1772 feet) in height (577.44 meters to the upper antenna), it is the highest freestanding structure in Eurasia.

One of several "Stalin's" buildings, large and massive.

A monument to Tchaikovsky in front of the Moscow Conservatory. Actually, I'm totally dumb in classical music and I'm a terrible singer. The only note I can strike well is C sharp :)

Just a nice place to walk around...

...or simply stand on a pedestal.

Let's finish our walk in a forest situated in Moscow outskirts where we found this cone... It is gorgeous, isn't it?

Just found a nice Microsoft KB article that shows how to change the way Internet Explorer opens linked Microsoft Word documents. By default, they are opened in-place in the browser window; many users seem require another behavior, when the documents are opened in a separate instance of Microsoft Word. I have tested it and it worked. Hope this will be useful.

You can read the article here:

http://support.microsoft.com/kb/254918

No doubts, Microsoft Visual Studio 2005 is not merely a "tool" for development. It's rather a powerful environment that includes everything we need for efficient and successful work. Unfortunately, it's an established fact that the first release of the environment proved to be too raw. There are quite many bugs for a product of that class, and some of them are pretty annoying.

Guys from Microsoft do realize this as well and finally they decided to relieve us from most of the troubles. Recently they've released Visual Studio 2005 Service Pack 1 (SP1). They claim in some areas it addresses more than 50% of the bugs reported by users. Good job. I didn't notice any major fixes though, at least it's still impossible to work with dynamic help on - too slow as before. However, I've just installed SP1 on my machine so hopefully it will show its worth during the work 

The most noticeable improvements offered by SP1 are:

• New processor support (e.g., Core Duo) for code generation and profiling
• Performance and scale improvements in Team Foundation Server
• Team Foundation Server integration with Excel 2007 and Project 2007
• Tool support for occasionally connected devices and SQL Server Compact Edition
• Additional support for project file based Web applications
• Windows Embedded 6.0 platform and tools support

You can download SP1 here:

• Visual Studio 2005 Team Suite SP1 (includes SP1 updates for Standard, Professional, and Team Editions of Visual Studio 2005)
• Visual Studio 2005 Team Foundation Server SP1
• Visual Studio 2005 Express Editions SP1
• Visual Studio 2005 SP1 Update for Windows Vista Beta - coming soon

No comments. I only hope this will be really useful for the industry as stated, not merely for the money makers:

Ron Hovsepian and Steve Ballmer take the stage together to announce a new collaborative relationship between Novell and Microsoft.

Novell and Microsoft are announcing an historic bridging of the divide between open source and proprietary software. They have signed three related agreements which, taken together, will greatly enhance interoperability between Linux and Windows and give customers greater flexibility in their IT environments. Under a technical cooperation agreement, Novell and Microsoft will work together in three primary areas to deliver new solutions to customers: virtualization, web services management and document format compatibility. Under a patent cooperation agreement, Microsoft and Novell provide patent coverage for each others customers, giving customers peace of mind regarding patent issues. Finally, under a business cooperation agreement, Novell and Microsoft are committing to dedicate marketing and sales resources to promote joint solutions.

http://www.novell.com/linux/microsoft/

http://online.wsj.com/public/article/SB116249026689311557-helTbrheLKgbaJ5iO5z40ZFCiOs_20061109.html

Recently Microsoft released a CTP of the next generation visual development tool. It is available to download here. If you don't like to install raw versions of software onto your working machine, there's a little surprise for you: the CTP is distributed as a Virtual PC image so you can download it and start playing immediately without impacting any existing software installations! Actually, the process of getting the CTP to run is slightly more complex as you also need to download another image containing a host OS etc. However, I think it's much better than installing products that are still under development directly into the system.

In general, VS 2007 is still very, very far from the final release. Only a small part of the C# 3.0 features is supported, IntelliSense doesn't work for many language constructs, and so on. However, this is just a technical preview. Good luck to Microsoft in development of our main working tool!

What class design do you prefer? I assume most of you follow Microsoft guidelines, and it's reasonable. However, practice shows that not all the recommendations should be blindly obeyed. I don't imply here fundamental rules like "never make instance fields public" (yet this also might be broken in some rare cases – imagine you have an internal class representing a low-level data structure with several hundred fields!). I'm rather speaking of naming conventions, order of members, and some other stuff related to the appearance of a class. I wanted to share few class design rules that seem different from most popular guidelines but proved to be useful to me and my teammates. I supplied each recommendation with a practical explanation of the reason.

Naming Conventions

Use m prefix for instance fields and g prefix for static fields + Pascal style name.

Why? Despite Microsoft recommendations, including prefixes in field names seems useful due to several reasons:

• Field identifiers cannot be mixed up with other identifiers, e.g. those of properties or local variables.
• No need in color highlighting (for example, offered by the ReSharper plug-in) to distinct field identifiers.
• IntelliSense sorts fields together thanks to the same prefix.
• Field look more "class level" than say when using camel style

It seems like controls should be the only exception. There is no strict opinion how to name the fields holding controls. I don't like both the popular styles: neither including a prefix (such as txtCustomerName) because Hungarian notation is considered obsolete in .NET, nor ending the field name with the control's class name (too long – imagine something like CompilationResultsRichTextBox3). So I'm just using Pascal casing (instead of camel casing offered by VS designers) until I find a better rule.

The Order of Members

The order of members inside a class:

Ctor
Methods
Static ctor
Properties
Fields

Why? Methods go first because when you open a source file in an editor, the first thing you want to read is normally what the class DOES rather than what data it works with. The instance constructor is the "initializing" method so it goes very first. The static constructor goes last because it's usually the least "important" of the methods – it normally contains nothing but static field initialization. Properties might be treated as a hybrid of fields and methods so it's logical to place them in the middle; another argument is that most properties are nothing but field accessors, hence they should be placed closely to fields. Fields are last because they are usually the last thing you want to get familiar with when exploring a class.

One can argue that it's reasonable to keep fields and their "wrapping" properties together. Yes, it makes sense because it allows easily remove a field and corresponding property if needed. However, inconsistency is our natural enemy so if we agreed to physically separate the code of the methods and the data they work with, let's stick with this rule.

It's a moot point which is the best place for events (not shown on the list), probably between static ctor and properties.

The order of members inside each group:

Public
Internal
Protected
Private

(Don't know where to put protected internal – have you ever had to create any? )

Why? Mostly because less visible methods are normally invoked from more visible ones. There may be exceptions from this ordering for example if a private method is a helper method called from one or more public methods; in this case it's acceptable to place this private method right after the public method(s).

Other Rules

Always explicitly specify the visibility of a class and its members.

Why? Just because it makes code more readable.

If a method does not refer to any of the instance fields, make it static.

Why? Because you can easily extract it later for example to a utility class.

Do not use #region blocks.

Why? Class shouldn't be so large to demand the use of #region. Refactor the class to a couple of smaller classes. Perhaps regions would still be useful say for separating methods and fields but they don't seem to have a decent support in VS (I was amazed when discovered that collapsing regions makes the contents not searchable).

So a "proper" class should look as follows:

    public class ProperClass
    {
        public ProperClass(int field1, int field2)
        {
            mField1 = field1;
            mField2 = field2;
        }
       
        public void PublicMethod()
        {
            InternalMethod();
           
            // ...
        }

        internal void InternalMethod()
        {
            int result = PrivateMethod(mField1);
           
            // ...
        }
       
        private int PrivateMethod(int inputValue)
        {
            // ...
        }
       
        private static string PrivateStaticMethod(string value)
        {
            return (string)gSomeMap[value];
        }
       
        static ProperClass()
        {
            gSomeMap = new Hashtable();
            
            gSomeMap.Add("Value1", "MappedValue1");
            gSomeMap.Add("Value2", "MappedValue2");
           
            // ...
        }

        public int Field1
        {
            get { return mField1; }
        }

        internal int Field2
        {
            get { return mField2; }
            set { mField2 = value; }
        }

        private int mField1;
        private int mField2;

        private static readonly Hashtable gSomeMap;
    }

So we have almost finished another major release of Aspose.Words. We're happy to note how greatly the component evolves and improves despite it's still pretty young by the standards of software industry. It's less than 3 years old but it's already the subject to imitate

Among other cool features, two highly requested formats have been added to the component's arsenal, Rich Text Format (RTF) and WordprocessingML (WordML). One of the areas I'm responsible for is RTF export (will start working on import once we release 4.0 final version) so if you are curious, I will share some interesting facts related to that.

Let me make some numbers public first. RTF 1.8 includes over 1400 keywords (called control words), and Aspose.Words now supports almost all of those required for proper representation of any Microsoft Word documents regardless of their complexity. The only exceptions are:

• Table styles
• Formatting revisions
• Comment ranges

All of these will be supported very soon.

At the moment we process around 95% of the keywords. That wasn't so easy mainly because RTF is a very ambiguous format. That is some keywords or their values just do not obey the rules declared in the format specification (which is also pretty ambiguous, but that's a separate story ). Another difficulty was the inconsistency that was showing itself throughout the format. As a result, the code of the exporter is full of comments specifying that some keyword behaves differently from what is stated in the spec, or may include an undocumented value, or is not mentioned in the spec at all.

Basically, RTF looks like the first attempt of migrating from binary to textual representation of documents. Yes, RTF is a textual format but it's hardly supposed to be read by a user  It's impossible to understand what \tsbrdrdgr or \lyttblrtgr mean having no description, isn't it? That wouldn't be a problem, though, if the spec was strict and legible and described each and every keyword Microsoft Word may produce. Unfortunately, I couldn't rely on the format documentation only and had to verify most of the keywords to ensure we produced documents looking exactly similar to the Microsoft Word's output.

Now I'm happy to state that all the problems are solved and the documents we're producing are identical to those created by Microsoft Word. Even their internal representation (I mean RTF stream itself) resembles Microsoft Word; for example, we satisfy old readers as RTF spec dictates (although we didn't test readers older than Microsoft Word 97).

That doesn't mean we blindly mimicked Microsoft Word. For instance, we have a test document containing several ClipArt shapes that when saved as RTF and opened again in Microsoft Word, crashes it. However, Microsoft Word perfectly opens this document when it is exported to RTF by Aspose.Words

Anyway, Microsoft Word is still exemplary for us because we're working with its "native" formats and our goal is getting rid of any differences between the appearances of our documents. I think we've succeeded in it. The accuracy we've achieved is the reason why we call our export High-Fidelity, or Hi-Fi, in case you were wondering. We spend a lot of effort in details. Here's an example. Microsoft Word has no UI elements that allow setting up such line properties as joining style or miter limit. However, these are present among the shape attributes and it's enough to us to be supporting them in RTF and other formats. We just do not ignore minor things even though they are used pretty seldom - who knows, maybe some of your documents will contain those attributes.

If nevertheless you find anything you treat as inaccuracy when exporting to any of the supported formats, welcome to the Support Forums. Many improvements of the product are reaction to your requests, and we are in extreme need of your participation in the development process. We hope recently launched Aspose MVP program shows that well. Together we will make it Hi-End!