ctodx

This Blog

News

Favorite Posts

Archives

February 2007 - Posts

  • Reminder: DevExpress at DevWeek 2007 next week

    I'm packing my bags and flying out tomorrow for London Heathrow, via Chicago O'Hare - just as they're predicting an ice storm (OK, "light freezing rain" it says here). I arrive at Heathrow on Sunday morning of course, having slept the night away en route. Mark gets in a couple of hours after me - he's coming another route altogether.

    DevWeek is sold out, which means it should be great fun. Remember: please do come over to our booth, introduce yourself, let us demo some cool things for you, and grill us on our roadmap. The exhibit hall is open on Tuesday and Wednesday all day, with Tuesday evening being the delegates' drinks reception in the exhibit hall, from 5:30pm to 7:00pm. I'm going to guess the crowds around our booth will be two or three deep during this time.

    Mark has one talk on Wednesday at 2:00pm (14:00) called Best practices with the .NET Event/Delegate Framework. If you've never heard him talk, you should come along: he's riveting, to put it mildly. The last time I attended one of his talks he roped me in as a Vanna White character, writing stuff down on my Tablet PC, projected on the big screen. Well, there wasn't a whiteboard in the room in spite of our having gone out the previous evening to buy a whole bunch of colorful whiteboard markers...

    See you there!

  • The Developer Express 2007 Roadmap

    When someone on our newsgroups heard a rumor that we might be publishing a roadmap, he invented a great one on the spot that reads, "Developer Express Roadmap: We will release a lot of new great products between now and Q4 2010; the next roadmap will be published Q1 2011."

    Yes, guilty as charged: we've been (in)famous for keeping quiet and ambiguous about what we're doing and when we're going to do it by. Well, this year, we've decided to open the kimono a little more than we've done before and have published our roadmap for 2007. You can read it here.

    Of course, the roadmap should come with a Surgeon General's Warning; things are likely to change, especially the further out we looked, so please don't have a heart attack if something doesn't come to fruition. Lots of things will happen in the months ahead and, despite our best prognostications (that is, the tea leaves from my early morning cup of tea), items on the roadmap will change in scope, be postponed, or even brought forward.

    I'm going to guess that publishing such a document is also going to generate a good deal of comment from our customers. We'll certainly be active in expanding and explaining certain things in the roadmap here in the blogs and on the newsgroups. Stay tuned!

  • Shall I compare thee to a summer's day?

    Every now and then we get asked for something that, although seemingly reasonable on its face, is actually something we'd rather not get into. This time, I'm talking about comparisons with our competitors.

    We just don't do them. We don't produce them internally and we certainly don't want to write and publish them externally.

    Why? Especially as it seems so innocuous a request: "Have you a document that compares your XtraFooBar product against AceFooBarCo's version?" One presumes the potential customer is sizing up our implementation against AceFooBarCo's in order that he can then place an order for a site license of 100 or more. W00t!

    My issues with this simple request are manyfold.

    1. If we did produce such a document, it would be biased. Well, duh. It goes without saying. It's not like we'd phone up AceFooBarCo and hammer out a comparison document we both agree on that we then both use; heck, no: we take a quick look at AceFooBarCo's version and write up a document.

    The bias may be deliberate (we happen to "forget" to mention that AceFooBarCo's version does X when ours doesn't). It may be an inadvertent mistake (we genuinely don't notice that AceFooBarCo's version does X because we're not looking for it since ours doesn't do X), or it may be that we stretch the truth a little (although we acknowledge that although AceFooBarCo's version does X, we say that we do something better which means you don't need X).

    So what are you, our potential customer, left with? A document you can't really trust too much.

    2. If we did produce a comparison document, its summary wouldn't necessarily be applicable to what you need for your project. Not quite so obvious a duh, but still one nevertheless.

    Look, only you know who you are writing an application for, what you want it to do, the data you need to work with and display and where it resides, the performance envelope you have to work within, and so on, so forth. One assumes that if you are going to write an application, you are going to have all these things pretty much nailed down. It's a far different application that has to accept 100s of simultaneous users on the Internet than one which is used by seven people in the accounts department. That difference translates into different requirements for your third-party products.

    But we, the people writing the comparison document, don't know all this. So we have to make it pretty general. We certainly don't want to write comparison documents for every scenario we can think of: our business is in writing components and tools and frameworks. So the comparison document would tend to have a fairly fuzzy out-of-focus quality to it: it may apply to what you're doing, it may be completely inapplicable, it most likely falls in between.

    So, again, you're left with a document you can't completely trust.

    3. If we did produce a document that compared our XtraFooBar against AceFooBarCo's, it wouldn't take long before we'd be asked for a comparison against FabFooBarInc's; oh, and don't forget GroovyFooBarLtd either.

    At some point, we just won't have time to do all this diligently and so we'll take short cuts. We'll select a bunch of features, A, B, C and so on where we feel we do well and then just compare those features. It's a case of introducing some subtle biases again. Of course, you could go to the competitor and check their comparison chart, but you'd probably find that they just compare features J, K, L and so on.

    And you're left with a document that's just not comprehensive and is bound to have biases.

    4. And then if we did have a whole bunch of comparison documents, we'd then have to maintain them though all our releases and our competitors' releases to make sure that they're up to date. We just don't have those resources available -- given the breadth of our products, it would be a full time job for someone -- and so I can imagine that it would only get done when we release our new versions.

    So you get a document that's likely to be out-of-date and therefore untrustworthy.

    5. And even then, if we had all these comparison documents and freely gave them out, eventually one of our competitors would take offense at something we'd stated in them. Maybe it's wrong, maybe it's not the whole truth, maybe they think we're not being fair, maybe they just object to our tone, whatever it may be we'll just get sucked into some bizarre vortex where we're arguing about minutiae with our competitors in some public forum, or worse there'd be some legal suit we'd have to contend with.

    And you, our potential customer, would have some great entertainment watching all this, but it certainly wouldn't get you any further towards your goal.

    It's a hackneyed cliché, but consider how you buy a car. Do you go to the Ford dealer and ask for their comparison brochure that measures up their medium truck against GM's and Chevy's? Nope. You do that yourself at home. You know what you what the truck for, and which features are important to you, and so you do the comparison yourself. You ask around, perhaps: what are other people saying about the trucks you're considering? A couple of test drives, some checking of financial possibilities, and you're all set with your choice.

    So, to summarize, please don't ask us for comparisons against our competitors, we just don't have them and we're not going to produce any.

    We'd rather say to you: here's what we do. If you can't see something you need, ask (we may have it, we may be doing it, or we may just say, sorry, no can do). If you want to see what other customers are saying about us, ask around or you can look here and here. If you want reviews go over here. If you want to compare prices you can get ours here. And so on.

    We believe that you're the best person to do meaningful comparisons because only you know what's important to you.

  • More RTL (and I don't mean run-time library)

    Although it seems as if I've been ignoring the comment thread for my post on RTL language support, I have been religiously reading everything that's been said there. I don't dispute that RTL language support is a good thing for us to do, or for any component vendor to have, I just have to consider the business rationale.

    In the past six months I have been watching our sales, especially their provenance. In very hand-wavy terms, our biggest market is the US and the second biggest, the EU. Third in the list is Australasia. After that, it's a toss-up, there's no real leader in the regions that are left (although, interestingly enough, South Africa is pretty strong).

    Hallvard Vassbotn's comment this morning gave me pause though. Although my analysis of where we sell is important, it doesn't give me the whole picture. What I hadn't really considered -- and with hindsight it's an obvious lack of foresight -- is that software companies, no matter where they're located (including our biggest markets), may be selling or wanting to sell into the Middle East and therefore need RTL language support.

    Nevertheless, I'm in a bind. In the next couple of days, we'll be publishing our roadmap for 2007. As you'll see, it's pretty complete (and we had to push the teams to reveal some of the detail). Also, it should be fairly obvious that the further out we prognosticate the more fuzzy things get. However, there's just not much room in there for extra unplanned work, like RTL language support.

    So, hypothetically, in order to do it we would either have to delay some of the things we're planning, or we'd have to employ more developers (and remember that we have two product lines at least to modify for Windows targets), or we'd have to contract the work out.

    The first option, especially after we publish the roadmap, would be a no-no. If we did, I'd love to sit on the sidelines to hear some of the explosions, but of course I'd have to don the asbestos suit and wade into the flames.

    The second option is a possibility, without a doubt, especially given that we are already expanding some of our teams; but then again we're only expanding them because we have some aggressive goals this year for them. We're certainly not expanding the teams in order to produce some slack to do other undefined projects.

    As for contracting out the work, it's very rare that we do it. The issue is that we also need to manage the project on our side and that requires one resource, and it's a team lead type resource at that. It's those resources that are in high demand already.

    So, I'm back to square one: it's worth doing, but I just can't see us doing it this year.

  • Breaking changes for DXperience v2007 vol. 1

    We're getting close to releasing DXperience v2007 vol. 1. How close? Well, put it like this: it's scheduled for the first quarter of this year, and so that means within the next six weeks. I will reveal though that we've hit code freeze, and for us that means no more new functionality will be entertained and we're now in a phase of testing and bug fixing and help file proofing and example program checking, etc, etc, etc.

    Actually, since we've hit code freeze, we're close enough that I want to take this opportunity to prewarn our customers about certain breaking changes that are coming down the 'pike. This is part of our new philosophy of keeping you, our customers, appraised of what we're doing at a much earlier stage than we've done before. This will help you plan how you're going to deal with our releases.

    Anyway, without further ado, here's the current list of known breaking changes. I emphasize that we haven't made these to annoy you, but instead to ensure that we can move the products forward to make them more relevant and needed than before.

    The first one is the biggest: DXperience v2007 vol. 1 will not support .NET Framework 1.0 or 1.1 any more, only version 2.0 or above. Similarly we won't support Visual Studio 2002 or 2003 either, only Visual Studio 2005. This breaking change has been in the pipeline for a while and indeed we surveyed our customers about it last year, with a vast majority of respondents supporting the move. (Remember DXperience v2006 vol. 3 will be supported and bugfixed for the foreseeable future, so if you are still using .NET 1.x you aren't being cut off.)

    In particular, if you are using our .NET components and suites in Delphi 2005 or Delphi 2006, please note that since these products only support .NET 1.x and so you will have to continue using v2006 vol. 3.

    Having got the big one out of the way, the rest of the breaking changes tend to be small and very product-focused.

    XtraEditors Library

    • The type of the BaseEdit.DefaultErrorIcon, BaseEdit.ErrorIcon, GetErrorIconEventArgs.ErrorIcon properties has been changed from System.Drawing.Icon to System.Drawing.Image.
    • The DXErrorProvider.GetErrorIcon event is now static.
    • The IDXDataErrorInfo interface signature has been changed.
    • The appearance of read-only editors has been changed due to the implementation of the following suggestion: A1741.

    XtraScheduler Suite

    • The MappingInfoBase.DataManager property now always returns null. You should not use this property in your code.
    • The SchedulerStorage.ResourceInserted event is no longer fired. You should use the SchedulerStorage.ResourcesInserted event instead.
    • The SchedulerStorage.ResourceChanged event is no longer fired. You should use the SchedulerStorage.ResourcesChanged event instead.
    • The SchedulerStorage.ResourceDeleted event is no longer fired. You should use the SchedulerStorage.ResourcesDeleted event instead.
    • The SchedulerViewBase.VisibleIntervals property now always returns null. You should use the SchedulerViewBase.GetVisibleIntervals and SchedulerViewBase.SetVisibleIntervals methods instead.

    XtraPrinting Library

    The following obsolete public members have been removed. Note that all these members have been marked obsolete for a long time and are now being finally removed.

    Removed member What should be used instead
    PageTableBrick.AddRow method PageTableBrick.Rows.AddRow method
    LinkBase.AddReport method LinkBase.AddSubreport method
    PrintControl.BrickContentZoom property This property doesn't have to be used at all
    ProgressReflector.SetActiveReflector method ProgressReflector.RegisterReflector and ProgressReflector.UnregisterReflector methods
    PrinterSettingsUsing.IsAllSettingsUsed property PrinterSettingsUsing.AllSettingsUsed property
    PrinterSettingsUsing.IsAnySettingUsed property PrinterSettingsUsing.AnySettingUsed property
    XtraPageSettings.UsefulPageSize property XtraPageSettings.UsablePageSize property
    XtraPageSettings.UsefulPageRect property XtraPageSettings.UsablePageRect property

    XtraReports Suite

    The following obsolete public members are removed. Note that all these members have been marked obsolete for a long time and are now being finally removed.

    Removed member What should be used instead
    XRControl.AutoHeight property XRControl.CanShrink and XRControl.CanGrow properties
    XRControl.BorderSide property XRControl.Borders property
    WinControlContainer.BorderSide property WinControlContainer.Borders property
    XRPageBreak.BorderSide property XRPageBreak.Borders property
    XRControl.TextAlign property XRControl.TextAlignment property
    XRControl.Style property You need to use appearance properties directly (XRControl.BackColor, XRControl.ForeColor, etc.)
    XRControl.EventScripts property XRControl.Scripts property
    XRPictureBox.SizeMode property XRPictureBox.Sizing property
    XtraReport.HtmlCompessed property XtraReport.HtmlCompressed property
    XtraReport.CreateFromFile method XtraReport.FromFile method
    XtraReport.UseDefaultPrinterSettings property XtraReport.DefaultPrinterSettingsUsing property
    XRControlStyle.BorderSide property XRControlStyle.Borders property
    XRControlStyle(Color, Color, XRBorderSide, int, Font, Color) constructor XRControlStyle(Color, Color, BorderSide, int, Font, Color) constructor
    StyleUsing.UseBorderSide property StyleUsing.UseBorders property
    PrintOnPageEventArgs.PageNumber property PrintOnPageEventArgs.PageIndex property
    XRScriptsBase.AddScripts(XRControl, XREventsScriptManager) method XRScriptsBase.AddScripts(XREventsScriptManager) method
    XRSummary.Value property XRSummary.GetResult method
    ControlViewData.BorderSide property ControlViewData.Borders property

    ASPxperience Suite

    ASPxMenu, ASPxNavBar, ASPxPopupControl, ASPxSiteMapControl, and ASPxTabControl: All the separate assemblies (DevExpress.Web.ASPxMenu.vX.Y, DevExpress.Web.ASPxNavBar.vX.Y, DevExpress.Web.ASPxPopupControl.vX.Y, DevExpress.Web.ASPxSiteMapControl.vX.Y, DevExpress.Web.ASPxTabControl.vX.Y) have now been united into a single assembly for the entire ASPxperience suite. The new assembly is called DevExpress.Web.v7.1.

    Remember that you don't need to change references to a new assembly in your project by hand. In fact, please don't: if you're anything like me you'll forget one or two and get frustrated. You should use the Project Converter tool instead.

  • Passion. Passionate. Passionately.

    As it happens, the question of passion came up in a few conversations I've had of late. Not passion in a sexual sense — sorry, everyone, this isn't that kind of blog! — but in the sense of an intense enthusiasm for something you're producing.

    I think that, in order to be successful at software development, you have to be passionate about it. You have to be passionate about the software you're writing and passionate about the problem you are solving with this software; or, at the very least, passionate about the solution to that problem. Jeff Atwood, in Coding Horror, summed it up like this when he was talking about how to become a better programmer:

    Passion for coding is a wonderful thing. But it's all too easy to mindlessly, reflexively entrench yourself deeper and deeper into a skill that you've already proven yourself more than capable at many times over. To truly become a better programmer, you have to cultivate passion for everything else that goes on around the programming. [...] The more things you are interested in, the better your work will be.

    If you are producing something for which you have no passion then that something just won't be as good as it could be.

    A friend of mine has been fighting an uphill battle trying to get her vision of the front-end of this older, large, complex application approved and staffed. To that end she and a small team have produced a prototype, and its implementation hit all the good practices: it was developed in an agile manner (this in a waterfall company), it's loosely coupled, it's functionally layered, it updates in real-time, it has full unit tests, etc.

    But it's been a struggle, not only deflecting roadblocks from upper management and from peers, but also from her own team who've wanted to take shortcuts. She succeeded in the end, not only through the extremely well-designed and functional prototype (after a demo, the sales people wanted it NOW dammit!), but also because of her passion for what she and her team were doing. She refused to back down, believing intensely in what they were doing, and instead fought for what she thought was right. It was her passion that made her succeed: after so many so-so projects at the company, this ability to show such intense enthusiasm affected the outcome on its own. No one wanted to stand in her way.

    Passion convinces people. Passion makes you an evangelist. Passion brings people round to your side. Obviously there must be something concrete there as well (having passion for vaporware won't win you many friends), but passion is infectious.

    Over the past couple of weeks, I've been helping a local high school prepare for a competition known as Mock Trial. Each school that participates puts forward a team to argue a fictitious case in front of a judge and jury, with another team opposing them. So, the team divides up into two parts: for the plaintiff and for the defense. Each side has its witnesses, three or four, say. In the competition the plaintiff team for one school will be married up to the defense team from another, and they fight it out in a mock trial. They get points for opening and closing arguments, for the believability of the witnesses, for counsel's objections, etc. After a few regional rounds, there's a state competition, and after that the winning school from the state goes forward to the national competition (which is in Texas this year). Great fun.

    I've been helping as a coach to teach the kids acting techniques to get their viewpoint across better and more forcefully. Tonight was the final rehearsal (the regionals start tomorrow afternoon), and so I gave a quick final bit of advice. And it was: be passionate. I said that, in order to win, not only do you have to be technically good and have all the facts memorized, but you must be passionate about what you're doing. You have to believe in what you're saying, and your passion will help convince the judge and jury. Dull recitation of previously learned lines won't cut it.

    A company like ours can suffer from a lack of passion. Some of the products, or new functionality, can come across as so-so, not because they're crappy or boring or me-too but because they have no champion who believes in them; who is passionate about them; who is willing to blog and talk about them.

    I was talking to Dustin Campbell from our IDE productivity team today about the issues we've encountered in producing our ASP.NET refactoring product. I put it to him, and he agreed, that the product only started gaining traction and becoming more stable and higher quality when people outside the team started using it and testing it and getting passionate about it. It's weird really: of all the teams in Developer Express, I would rate the IDE productivity team as possibly being the most passionate about their product, but even they can get jaded about some functionality that's outside their normal day-to-day work (they don't use ASP.NET at all).

    This conversation with Dustin this morning made me step back a bit, and do some thinking. The employees at Developer Express are, by and large, very passionate about the products and proud of the company and what it does. I think that passion comes across very well to the outside world. But there are gaps, sometimes large gaps. I don't think we ("The Management") can instill passion in someone for something they're not interested in, but I think we can encourage and cultivate the passion that's perhaps simmering under the surface. I believe that if we do and we're successful at it, our products will become better and more attractive. (Ah ha, the sexual theme again!)

    So, watch out, world. We've got fuses and we're going to light them!

  • Screencast for ASP.NET refactorings

    We've just uploaded a new screencast showing off the new ASP.NET refactorings with our Refactor product. Mark Miller and I get into and clean up his design for the online ordering application for his new Pizza Pit franchise. (There are two versions of the video: a low resolution and a high resolution one.)

    As it happens, the screencast is for a new product called Refactor for ASP.NET that just contains the ASP.NET refactorings from Refactor! Pro 2.1. We've joined forces with the ASP.NET team at Microsoft to provide you with this as a free download, much as we teamed up with the VB team to offer you a free Refactor for VB. The product is in the final stages of production, and the Microsoft ASP.NET team will be formally announcing it and providing the download link once we're happy with the quality and stability.

    If you've already got Refactor! Pro 2.1, you don't need to download this product (once it's available) since you already have all the functionality. Nevertheless, watch the screencast: you'll get a great feel for the new refactorings, and I'll admit Mark and I were on a roll. Mehul Harry, evangelist for our ASP.NET products, liked the "Millinator-style presentation", whatever that means...

     

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, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

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