This Blog


Favorite Posts


May 2010 - Posts

  • Computing Appliances and Walled Gardens

    Walled Garden I was ferreting through some of the dustier by-ways of my data drive (I never delete old stuff — it just sits there and accumulates cobwebs) when I came upon this article from Thanksgiving, 2004, some five and a half years ago.

    I had occasion after the turkey dinner yesterday to muse a little on computers and software in the retail channel. Well, my brother-in-law-to-be was waxing lyrical about the TiVo he'd just bought, and rather than restrict my thoughts to just that device, I started thinking about the retail channel as a whole for these computer and software driven one-use devices.

    First, we have the TiVo, essentially a Linux box with some TV hardware, a big hard disk, and some fancy software. It's certainly a one-use device: it "merely" enables you to record TV programs and play them back. (I'm deliberately minimizing discussion of the features of TiVo here; my intent is not to market it to you.) Despite the fact that it's a pretty standard PC, there's been no attempt to make it available for other uses. And, there are other set-top boxes out there that perform the same kind of function, some better than others, some with extra features, all based on PC hardware as far as I know.

    Second, we have the Apple iPod. A tiny computer with a hard disk that is designed for one thing and one thing only: playing digital music. The latest version is a color device and doubles as a digital photo album. But why is an iPod so popular when modern PDAs can also play music?

    Third, we have the Xbox and the other game-playing consoles. A device that can only be used to play games (although, it must be noted, many people have hacked Xbox to do other things). Compare that to a standard PC, which can also play games, but has so many other uses as well.

    Fourth: cell phones. These are a great appliance, although they are starting to become more and more flexible in the sense that their OSes are opening up to other software. But as they become more flexible, we are in a great danger than their optimized-for-phones keypad will disappear (for a touch screen, perhaps), or grow (with extra buttons).

    Last, there's calculators. To be honest, a calculator's functionality, including graphics, could be done equally well with a PDA (on my Clie, I use a programmable RPN calculator app called MathU Pro that mimics HP calculators). But calculators are still being designed and sold.

    My thought here is why do these appliances or one-use devices fare so well? After all there is nothing more flexible, more able to have multiple uses than a standard PC or PDA. I think it's to do with that very flexibility. We want our appliances to be designed for their stated purpose. We don't want the appliance to be flexible, because with flexibility comes the inevitable blurring of functionality for the device's one true purpose. Imagine if the iPod used a Palm-like handwriting recognition engine with a touch-sensitive screen. It could then possibly be used for far more than just playing music. But it would lose that impressive geared-for-one-purpose-and-do-it-well user interface.

    Another benefit of appliances is that they seldom crash. There's no other, possibly rogue, software running on these machines. Their operating system is geared to the one use. It used to make me laugh when I worked in Las Vegas, walking down the strip and seeing the giant displays outside the Paris casino showing a Windows 98 blue screen. Using a PC to drive these displays seems innocuous enough, no? Imagine how much better if there were an appliance that did the same job.

    So I can see appliances continuing to have a great market share compared to "special" software on a standard PC that mimics the appliance's function. And I can foresee that Linux will have a big role here: it's easier to produce a specialized OS for a device with Linux than anything else.

    I realize that Microsoft is trying with Windows Media Center and Windows Mobile to target these appliance markets, but their big problem is that it's the hardware manufacturers who dictate the agenda here. Suppose, for example, that someone, HP say, were to provide a photo printer with a photo editing function. You slip your camera's memory card into the printer, and through a tuned-to-photo-editing user interface you can tweak the contrast, brightness, and color balance of the photos and remove red-eye and crop the image and all that fun stuff before printing. Do you think that would be a big seller? Do you think it would be running Windows under the hood? To me the answers are yes and no.

    Long live the appliance! Now, how do I get a piece of the action?

    Well, apart from the fact I completely missed the genesis of the iPod Touch (and I got no piece of the action), I think the article still stands pretty well except for one thing: the iPhone and the iPad. Here, instead of the one-use appliance, we have what might be called the “walled garden” appliance.

    In a walled garden, you can grow anything you want in the secure knowledge that nasty stuff from the outside can’t get through the walls. You are protected and pretty safe. In order to do so, of course, you have to follow the rules of the walled garden, otherwise what you grow may rot and bring down the walls. The user experience and development environment for the iPhone OS is a walled garden: you can only do certain things (Objective-C, XCode), and you have to get what you want from the overseer of the garden (Apple App Store). But, apart from that, have at it.

    But, really, does that protection make it a safer place? Is the walled garden appliance safer? A couple of news items I read today are noteworthy.

    First, the head honcho at AT&T’s Business Solutions division, Ron Spears, was playing up the fact that 40% of iPhone sales are to enterprise users these days. Why? Because of the new enterprise-level features and “the kind of modern, tight, full-featured security that your average IT department needs.” Heck, yeah. iPhones are secure because you can’t get any of that nasty, un-vetted, virus-carrying crap on it — everything comes from the App Store (or presumably from your enterprise IT department if they bought that level of the Apple Developer license). (Read the article from Engadget.)

    Second, Chester Wisniewski of Sophos, the security people, pointed out in his blog that the iPhone is pretty unsecure: just plug it into your nearest Ubuntu box and read off the data. Some data seems to remain secret/encrypted, but, really, now that someone has worked out how easy it is to access the iPhone’s storage, how quickly will it take for the rest to fall?

    So walled gardens are fine as long as you trust the owner to build it properly. But don’t poke at the walls too hard, you may find they’re made of polystyrene.

    (Post scriptum: I actually still use MathU Pro, but now on my iPhone. Awesome calculator app for RPN gurus.)

  • DXperience v2010 vol 1 has been released

    We released DXperience v2010.1.4 this lunchtime. It’s now available in Client Center, so just go there, log in, and download. Enjoy!

  • DevExpress Newsletter 28: Message from the CTO

    Here’s my message from the 28th DevExpress newsletter. It’s written as a script between Amanda and myself:

    Julian: Just over 10 years ago, Kent Beck wrote a slim volume called "Extreme Programming Explained" that discussed a new methodology for designing and developing applications.

    Amanda: Extreme Programming was one of the first attempts to impose an Agile methodology onto a development process and to avoid the so-called Waterfall method.

    Julian: In the book, Beck laid out a dozen rules or practices that define Extreme Programming, covering all aspects of team development of software. One of them stood out in particular and seemed to generate more controversy than any of the others.

    Amanda: Pair programming. This is the technique where code is written by two people at one PC.

    Julian: One of the developers has control of the keyboard and is writing code.

    Amanda: And the other is watching, making suggestions, thinking further forward about the problem space.

    Julian: You can think of the pair as being the tactical and strategic partners. The tactical partner is writing the immediate code required. The strategic partner is considering future directions and problems.

    Amanda: Short term goal driver and long term goal navigator, if you like.

    Julian: Every half an hour or so, the pair switches places: the navigator becomes the driver and vice versa. The partners are not stuck in place for the whole day. Furthermore, you pair up with someone else the next day, and so on.

    Amanda: The benefits of the approach are manifold. For a start having two pairs of eyes means bugs are spotted earlier. Bugs caught early are much easier to fix and cost less than bugs discovered later.

    Julian: Having pairs mean that the code is understood by at least two developers. Knowledge of the code and system gets spread across the team.

    Amanda: Learning of the system and training of new hires is enhanced through pair programming. Cross-fertilization of knowledge is improved.

    Julian: And the quality of the design tends to be better since two heads are better than one in coming up with design ideas and the like.

    Amanda: Overall, despite the complaint that you're paying two people to do one person's job, the quality and the robustness of the resulting software is much better using pair programming than with the traditional way.

    Julian: So, why don't you try it...

    Amanda: Next time...

    Julian: You have a thorny software problem to solve...

    Amanda: That might be helped by pair programming.

    Obviously I wrote it expressly for videoing (“direct to video”?) but the sentiment is real. We use pair programming in R&D, not necessarily everyone, full-time, but the more complex the problem, the more likely there’ll be pair programming going on.

  • DevExpress Newsletter 27: Message from the CTO

    Here’s my message from the 27th DevExpress newsletter.

    Normally for a big conference event like Tech·Ed, we, as a company, go hell-for-leather for a big glitzy booth and wow the customers and passers-by with our demos, displays, and product innovation. You just have to look back through our blog posts here for the PDCs and Tech·Eds of the past to see what I mean. Of course, in order to provide this experience, we spend quite a bit of money.

    This year, though, we paused with our metaphoric pen on the dotted line. You see, Tech·Ed 2010 is taking place in New Orleans.

    I'm sure like me you were horrified at the extreme flooding of New Orleans caused by Hurricane Katrina in 2005. Levees were breached (in 53 separate places), leaving roughly 80% of the city flooded. It was the first time that the Mayor had ever ordered the complete evacuation of the city, but even so over 700 people died as a result of the flooding.

    Of course, if the flooding wasn't bad enough, the immediate aftermath was extremely painful. The Army Corps of Engineers had to rebuild or repair the levees, some having failed due to design flaws. Over 200,000 houses were damaged or destroyed and 800,000 people displaced. Even now, getting on for five years later, houses are still being repaired or rebuilt and families are still having to live in temporary accommodation.

    We at DevExpress can only wonder at the horrors of losing our homes and belongings due to this awful disaster. We've just never experienced such events. In thinking about it, we came to the realization that we cannot in all conscience spend what we normally do on a booth for three days and just leave. We didn't feel it was right.

    So we've decided to rent a small basic 10x10 booth at Tech·Ed and put the rest of the money we'd normally spend towards building a house. We've joined in partnership with Habitat for Humanity to build a new home for a deserving family in New Orleans. It's shocking to realize that the cost of a large booth at an event like Tech·Ed is in fact the price of a new house, but there you go. At least with this Tech·Ed, a family will soon have their new home.

    Of course, New Orleans and Louisiana are now facing another disaster, the BP oil leak, so this effort becomes even more apt.

  • Release date notes for v2010.1

    You’d think after four years in this job I’d stop with the prognostications and promises about when products will ship. But no, I reload the old release-date shotgun and shoot myself in the foot.

    Yesterday afternoon, the R&D teams got together to review the current state of play with regard to the v2010.1 release after a weekend of the Release Candidate 2 (RC2) being used. As the reports were presented around the table it became clear that the teams weren’t happy with the current quality of the release. Although everyone agreed that there weren’t any stop-ship bugs, there was a high level of “medium-level” bugs which were likely to be hit but that had some kind of workaround.

    Some discussion later and the decision was made to delay the release for a (hand-waving) couple of weeks to address the majority of these issues.

    So, if you are waiting for the final release of DXperience v2010.1 please be patient a little while longer: it’ll be worth it. Of course, if you already have DXperience, you already have access to RC2 from Client Center. We’ll be back in touch once we’re happy with the quality and robustness of the release.

  • DevExpress support for Visual Studio 2010

    This has come up a couple of times, so it’s best I clear up what we’re doing about supporting Visual Studio 2010 before we release DXperience v2010.1 (and that is so close I can taste it all the way over here in Colorado from Glendale). I think it’s best expressed as a flowchart-y thing.

    1. Are you using Visual Studio 2010? If yes, goto 2. If no, goto 3.

    2. You need DXperience v2010.1 (or later, obviously). Earlier versions of DXperience will not work with VS2010. We’ll be releasing this version any moment now (so I’m told). Goto 5.

    3. Are you writing Silverlight and/or WPF applications? If yes, goto 4. If no, goto 5.

    4. You need to upgrade to Visual Studio 2010. Really. No kidding. It’s an order of magnitude better. Apart from that, the thing is that we’ve rewritten our WPF and Silverlight controls to use a common core codebase, and this common codebase as well as the new designers require .NET 4 and Visual Studio 2010. So if you are writing Silverlight and/or WPF applications, upgrade to VS2010 and goto 1.

    5. That’s it.

    I hope that clears it all up...


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


DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, Delphi, HTML5 or iOS & Android development. 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-2018 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners