Blogs

This Blog

News

Favorite Posts

Archives

ctodx

Discussions, news and rants from the CTO of DevExpress, Julian M Bucknall

September 2006 - Posts

  • New tutorial screencasts available

    Just a quick announcement:

    Our documentation team has just uploaded four new screencasts to our website on the basics of using the XtraBars library and .XtraLayoutControl.

    XtraBars screencasts
    XtraLayoutControl screencasts

    The first video for XtraBars discusses how to create a simple form with a menu bar, a bar and a status bar, and how to add items to each, and how to set images with each item.

    The second video for XtraBars discusses the docking functionality within XtraBars and quickly produces a form with Visual Studio-like docking abilities.

    The first video for XtraLayoutControl discusses how to use the layout control by dropping and rearranging controls on it, both at design and at run time.

    The second video for XtraLayoutControl discusses the grouping of controls on the layout control, as well as how to hide groups and how to make them into tabbed pages.

    They've done an excellent job with all of these videos: they scripted them, recorded the visuals, and produced the final screencasts. My only involvement was limited to doing the narration in my best Richard Burton impersonation. Enjoy!

  • Visual Studio and Vista

    Some interesting news appeared on Somasegar's blog this morning (in essence, he's in charge of devdiv at Microsoft, those awfully nice people who bring us Visual Studio).

    There were two main points to his latest post:

    1. The first beta of Visual Studio 2005 SP1 was released this morning. To which we all heave a huge sigh of relief having wondered what the heck was happening when SP1 was released for VS2003. It seems they had a choice: ship SP1 with (or soon after) Vista, or decouple VS and Vista and prepare to ship the service pack first. They chose the latter, which is good news in a way (we get fixes earlier) and not so good news in another (there will have to be a "top-up" release soon after Vista ships). Anyway, we should be getting the actual SP1 release in the next 3 to 4 months, which makes it a New Year present.

    2. And then he talked about what will or will not work (or, rather, be supported) with Windows Vista.

    I'd like to delve a little more into this second point of his post, but first here are the actual facts from it:

    a. Vista will ship with .NET Framework 3.0. (This is essentially an add-on to .NET Framework 2.0 that supports the WPFs and WCFs and WWFs WFs of the new world.)

    b. Applications that use .NET Framework 1.1 and 2.0 will work on Vista.

    c. VS2002 and VS2003 are not supported on Vista.

    d. VS2005 is supported on Vista; it is the development environment du choix for Vista.

    e. Both the VB6 IDE and run-time will be supported on Vista.

    OK. Now you've had time to digest that a little bit, let's talk about what wasn't said. First, .NET Framework 1.0 is not supported on VIsta. Now, I suppose what I mean by this statement is that may work or it may not, but that they're not actively testing for it. OK, to be honest, I'm not too bothered by this: .NET 1.0 is long gone and so is VS2002.

    Second, I just don't know whether the fact that VS2003 is not supported in Vista means that, although it has no support, you'll be fine using it, or that there are some issues with running VS2003 in Vista, but that they're not going to actively try and work out what they are and fix them. Indeed Soma says that you can use VS2003 on Windows XP to develop applications that target Vista. This is fine as far as it goes, of course, but I reckon anyone who does that for a living will soon go batty and upgrade to VS2005. (And if I were cynical, I'd say ah ha!)

    It also speaks volumes that they're willing to go the extra mile for VB6's IDE (yes, the last VB before dotnetification), but not for VS2003. Why? Is it more important that VB6 developers are able to develop and deploy on Vista rather than VS2003 developers of all stripes? Why can't they develop on XP and deploy on Vista? If it's good enough for VS2003 developers (who presumably have spent money with Microsoft more recently than VB6 developers), why isn't it good enough for VB6 devs?

    Tough cheddar if you're a VC6 developer, by the way: you should be using VS2005, don'tcha know.

    And my cynicism meter is redlining so I'd better stop right now.

     

  • Breaking changes

    Sometimes, even with the best intentions, we make a mess of our component upgrades. Not with the new or improved functionality you understand, but with backwards compatibility and introducing breaking changes. Sometimes the effects of this mismanagement are minor, other times you, our customers, are faced with a barrage of compiler errors when you update your projects to use our improved components from the suite's latest version.

    Backwards compatibility: dread words that strike terror into the hearts of developers everywhere.

    Let's get one thing on the table straight away -- and I'm sure this won't be a surprise to anyone who's been writing software for a living for a while. Backwards compatibility is hard: you have to dedicate time and resources to it and you break it at your peril. I'm always impressed that MS have done so much for so long to make sure that your old DOS and Windows 3.1 programs still work in the latest versions of Windows, including the Vista-to-be.

    The main reason why it's hard is that developers as a whole want to provide better, more functional, faster software with subsequent versions of their products and to do that will sometimes require making breaking changes: changes to the UI of an application, to the programmatic interfaces of a library, to the schema of a database that mean the existing functionality of the software doesn't work in the same way as before .

    You publish your version 1.0 of a product. Now, to get version 1.0, you generally don't have the luxury of ample time to spend on forward-thinking design so you wing it. You make assumptions about what will need to happen for version 2.0 and you try and bake that into your code now. You try for extensibility and flexibility, but in reality you don't have the time or resources (or the business need) to do it properly. Of course, overriding all that is what will happen when version 1.0 is released. Will it be a flop? A success? If a flop, you'll be chucking the code to some extent pretty quickly and moving on. If a success, what will the customers ask for to extend it, to make it better? I can bet their requests and suggestions won't be anywhere near what you envisaged, so your careful preparations will come to naught. And knowing this beforehand, just makes it more likely that you don't spend too much time designing for the future.

    Unfortunately, if your version 1.0 is a success, you are now locked in to the expectations of your customers, and those expectations will include a "make it better, but don't break it" component. To be fair, customers (for we all are customers in one shape or form) will sometimes countenance a "if you must break it, break it big, but make it utterly compelling to upgrade" possibility.

    Back in the late 80s, Canon were faced with a problem. Their SLR cameras were selling well, were very well liked, but they wanted to produce a new line of electronically-controlled SLR cameras (the EOS series) that could do auto-focus and auto-exposure. Unfortunately, their current line-up of lenses were hampering them. So they did a very brave and risky thing: they brought out a complete new range of lenses (the EF series) together with their new EOS camera bodies. Now, you've got to understand that lenses, especially telephoto zoom lenses, are expensive. In essence, Canon told their customers that to move forward, they would have to purchase all their lenses again after buying a new EOS camera body. As it happened, the EOS series was a massive success because the cameras were so easy to use for non-professional leisure users (that is, there was a whole new market out there), and so compelling for existing users to upgrade (at some cost to themselves, obviously).

    So, with a version 2.0 of your product, you have a choice: make sure you're backwards compatible and provide incremental enhanced functionality, or produce an utterly compelling upgrade but break compatibility big-time. In general, we tend to go for the first option: there's much less risk involved.

    Of course, in moving forward incrementally, you will be faced with decisions about making minor breaking changes. Sometimes changes can be hidden from the user, but a lot of times it can't. For example, my wife's new Acura TL has a computer-controlled accelerator pedal which is no longer connected by cable to the engine. Instead a computer monitors how much she depresses the pedal and electronically revs the engine. To her the accelerator works in exactly the same way as before, but is just a smidgeon more responsive (an example of a non-breaking change). Conversely, the switch for the sunroof has moved from the lower left of the dash up to the roof (an example of an admittedly small breaking change).)

    Next time I'll be more specific and talk more in depth about what we do (and will be doing) at DevExpress to mitigate the problem of breaking backwards compatibility.

  • Catching up...

    I'm sure that it's the same for you: you go away on vacation, have a great time, come back and your email inbox is stressing out your disk free space (or Google are writing you that you're getting close to exceeding their limit). And if you read a whole bunch of blogs, ditto or even double ditto. So yesterday I finally caught up with a whole bunch of posts that had happened while I was over in England visiting family and friends. Here's a link dump of some interesting ones.

    • Joel Spolsky seems to be getting more and more reactionary in some ways and more hidebound in others. For some reason, he noticed I was away and then published a whole bunch of frankly bizarre posts to greet me on my return:
      • A pretty good series on filling your job vacancies, although I wonder if one reason I enjoyed this series if that it pandered to some inner need I have to feel like a rock star.
      • A good post with a nutty ending where he revealed that FogBugz had been written in an internal language they'd developed called Wasabi. Reading between the lines, it seems to compile to VBScript on Windows platforms or PHP on Unix ones. This is interesting in that other companies are doing similar things, but I don't know whether it's feasible for everyone, or just a cool way to approach something that has been solved by other (less cool?) means before.
      • An even more surreal post where he justified creating Wasabi (because Fog Creek didn't want to be involved in the tech support issues of installing other things in order to make FogBugz run?).
      • To crown it all, a post against Ruby where he seems to reveal a propensity for argument from ignorance.
    • The best counter-argument to Spolsky was made by Jeff Atwood on Coding Horror; although John Lam on Less is Better had some good remarks. It is extremely interesting that Microsoft has released IronPython for the .NET Framework and Sun bought out the JRuby guys, both within the past couple of weeks or so: evidence that dynamic typing languages are becoming more and more mainstream.
    • Avi Bryant merely proves Joel wrong, and talks about a way of method dispatching I hadn't heard of before.

    But enough about Joel Spolsky. Moving right along...

    • Eric Sink wrote a good article (as usual) on code coverage (OK, that was after I came back, but I didn't get to read it until yesterday anyway).
    • Joe Duffy, CLR PM at Microsoft, has rapidly become one of my must-reads on multithreading and on the CLR in general. It seems that he's been working on a prototype of parallelizing LINQ queries and has had remarkable success in doing so, to the point of Anders becoming interested in and promoting the technology. Duffy calls his project PLinq. No news on how soon we'll be able to play with it though.
    • Another of Duffy's posts from just before I went away: Why Sleep(1) is better than Sleep(0). This post typifies exactly why I've subscribed and read him assiduously.
    • On a week when -- yet again -- someone I used to work with started spouting nonsense about how .NET's garbage collector works ("it uses a reference count in each object, right?"), I find Maoni's WebLog provides invaluable information. Her latest is about what's significant when you try and analyze -- let alone solve -- memory issues in your .NET app.
    • Rico Mariani had a performance quiz on value-based programming. It and the subsequent post were very illuminating.
    • Oh, and our very own Mark Miller decided to end his professional career. We're keeping him in isolation with minimal contact with anyone except trained psychiatric professionals. His newsgroup posts are being written my a ghost writer until further notice.

     

LIVE CHAT

Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383

FOLLOW US

DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. Whether using WPF, Silverlight, ASP.NET, WinForms, HTML5 or Windows 8, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2014 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners