You've reached the internet home of Chris Sells, who has a long history as a contributing member of the Windows developer community. He enjoys long walks on the beach and various computer technologies.
Friday, May 16, 2003, 12:00 AM in The Spout
My First Talk As A Microsoft Employee
On Wednesday, I gave my first talk as a Microsoft employee. I was told that the talk was for a bunch of UK folks that needed to be put on the .NET path and could I do 90 minutes on intro to WinForms in a conference room on campus? I can do intro to WinForms material for hours without preparation, so I didn't do any. Instead, I showed up with my laptop and plugged it into the overhead, where I then spent 10 minutes wrestling to get it out of suspend mode (the world needs faster hard drives!).
While my HD woke up (apparently jet-lagged from the trip between building 5 and building 43), I started warming up the crowd with questions "How many of you are C++ programmers? How many VB programmers?" The room was split pretty evenly between C++ and VB, taking half of my jokes away (I'm happy to make fun of either C++ or VB programmers equally, but it's less fun when only half the room laughs). Plus, these guys were *way* jet lagged, so getting them to even keep their eyes open in the afternoon after they'd arrived was a challenge, let alone getting them to laugh or even engage.
And then, because my HD was still shaking off the dust, I asked "Did you hear anything good today?" Predictable, they said that they'd like the story of web services (Don had been there earlier in the morning) and that caused me to launch into my rendition of how WinForms + Web Services provided a wonderful way to keep all of the UI logic on a single machine, as opposed to web applications, where the UI is split between the client and the server. They weren't biting.
Plus, after diving into some WinForms intro material and having it fall flat (anchoring and docking normally wows 'em), I did a bit of deeper digging into my audience. It turns out that most of them were old hands at WinForms, throwing my planned material right out the window. Luckily, I did find a topic that they're weren't familiar with: href-exes. So, I did my normal href-exe shtick for about 60 minutes, getting them to wake up, ask questions and even laugh a bit at my witty repartee.
Thinking I was in the clear, I opened the floor for questions. Of course, the first question they asked was the same question I'd have asked if I were in their shoes (as I so often was until about a month ago), "What's new in WinForms 2.0?" And that's where things got shaky again. I had some ideas of where WinForms 2.0 was going in the next release of .NET, but nothing concrete (I've been buried in Longhorn and a whole new culture too deep to dig into WinForms futures yet). Plus, even the things that I did know, I had no idea what I could say. Where these guys under NDA? What could I say to them if they were? What can I say to them if they're not? Even if I'm not supposed to say anything, I want them to like me (every speaker's guiding principle) and I wanted to say something besides "I know, but I'm not going to tell you. <bpffffft>!"
So, I stammered out what I knew to be some WinForms desires without making any promises on their behalf and hoping no one would ever know (except my closest friends reading this spout entry : ). It wasn't a happy experience. I should have talked with the WinForms guys before my talk so I knew what I could say about the future. Rookie mistake #1.
Rookie mistake #2: In an effort to stay open to these guys, I wrote my alias on the flipchart and then, while I filled in the domain, kept answering questions. When I looked back at the flipchart, I discovered that I'd written "csells@sellsbrothers.com". Doh! Since it was a flipchart and not a whiteboard, I couldn't even erase it. <sigh>
All in all, I think I got them jazzed about href-exes, but it was definitely not my finest talk. Luckily, it was internal and to a small group; I would have been mortified to have given that performance at a larger venue. Plus, making fun of VB programmers isn't fun anymore. I mean, they're customers, too. Looks like I'm going to need some new material...
Friday, Apr 25, 2003, 12:00 AM in The Spout
My First Week @ MS
Friday, April 25, 2003
After my first week at Microsoft *everyone* wanted to know how it went, both internally and externally. I learned some things:
- I learned that folks at MS will call a meeting for lots and lots of reasons, including at the slightest sign of confrontation or hurt feelings. For a guy that hasn't really attended a meeting in the last decade, this is quite a switch : )
- I learned how to schedule a meeting w/ multiple people and a conference room (listed as "conf room <bld>" in the address book), all with conflicting schedules and all remotely using Outlook Web Access and without a SmartCard (I was pretty proud of that one, actually : )
- I learned that no one uses the phone for anything -- instead, they schedule meetings
- I learned that it's the person that wants something that does the actually scheduling of the meeting
- I learned that it's OK to open your laptop in a meeting, otherwise when would you get any work done?
- I learned that it causes quite a stir when you disagree with the technical lead of one of the major pieces of technology that you're supposed to be taking to the world
- I learned that it's darn hard to find out who to talk to your first week, and that you should take your boss to most of your initial meetings so that s/he can make sure you're getting what you need to get from them
- I learned that you can mix Exchange and POP3/SMTP to keep your new and your old email addresses going, if you use Office 11 and if you are willing to give up calendar and follow up notifications on your POP3/SMTP account (have I missed something?). I also learned that internal MS support doesn't help w/ such things.
- I learned that internal MS support is the greatest support in the whole darn world. These people don't let you off the phone 'til everything works. They're amazing
- I learned that you can volunteer for absolutely anything you think is cool or important so long as you get everything else done, too
- I learned that it's not good to ask for NDA access to super-secret bits for your friends the week before you start working there (OK, I'm pretty sure I knew that before, but I had to try... : )
- I learned that the right folks hanging out at lunch can make all kinds of interesting things happen
- I learned that MS and it's employees is the most charitable company in the country (world?)
- I learned that the internal resources for MS employees are unbelievable. I could work their my whole life and never take advantage of all of them
- I learned that it's important to sign up for your benefits immediately if you're going to be remote w/o a SmartCard for a while, otherwise your son may wake you up in the middle of the night with a hard toothache and when you take him to the dentist the next day, the dentist won't be able to confirm your dental insurance (as one example : )
- I learned that most everyone at MS is very nice (even when they're telling you to f-off)
- I learned that everyone (and I'm no exception) has a hard time fitting in at first. One interviewer told me that his first 6 months at MS were the worst of his life. I pray that it doesn't last that long for me
- I learned that after the initial period that few that survive it would ever think of leaving. I absolutely see how that could be
Monday, Apr 21, 2003, 12:00 AM in The Spout
"Look with favor upon a bold beginning"
A couple of weeks ago, I was having lunch with my wife at a little Chinese restaurant. My fortune was the title of this spout piece. I immediately associated it with my recent job interview at Microsoft and it made me smile. I had already pretty much decided to take the job, but it was nice that the Universe agreed with me. : )
Right now I'm sitting in NEO (New Employee Orientation) for Microsoft employees. Not only is it a cool name, but the nice folks at Microsoft provide a wireless network for new folks that can't spent hours w/o one (although I'm the only one that's geeky enough to have his laptop out at the moment : ). I start today as a Content Strategist on the MSDN content team at Microsoft, Corp. I'll be in charge of the Longhorn DevCenter. A DevCenter is a section of the MSDN web site that focuses on a specific technology area, like the XML/Web Services DevCenter.
Longhorn is Microsoft's next major operation system (and different than Windows Server 2003, which is the OS that Microsoft is launching this month). I can't (yet) say anything more about Longhorn except that it's cool enough that I took a job at MS so that I could get my hands on it. If you are dying for more info on Longhorn, but aren't quite ready to change your employment arrangements to get it, check out the PDC in October. And, if you stop by and say "hi," I'll show you the implant scars... : )
Thursday, Apr 17, 2003, 12:00 AM in The Spout
XML For Humans
When I sat down to write this piece, I didn't get why the work that Don, Gudge, KeithBa, Yasser, Tim and ChrisAn is doing is so amazing. I mean, I know that they're smart and I know that they're building the hell out of their stuff, but why? It seems like everyone that gets into blogging starts by writing their own blogging engine. It's like C programmers writing editors, C++ programmers writing string classes and XML programmers writing XSD<->Class codegen. Sure, it's a useful learning tool, but earth-shattering? Worth that much energy from that many guys? When they're done, what great problems will be solved?
Don't get me wrong. I love the that the web makes it easy for anyone to not only publish but also get an audience. I also love that there's a protocol (RSS) that lets me subscribe to my favorite freelance authors in any one of dozens of tools (I'm into SharpReader today). I even like the Dear Diary style of writing because it leads itself to thoughts, feelings and insights that give me greater understanding of not only the topic but the author. As an added bonus, blog entries have turned into everything that's good about mailing lists w/o the endless angle brackets that remove the need to write in coherent sentences. Blogs feel like the kind of democracy we had that lead to the American Revolution when the world was re-shaped with big ideas, written by great authors.
But does the world need yet another blog engine? Personally, while it's primitive, I find that FrontPage have served me well as a blogging tool. The mental overhead is small, the development is nil and I get red squiggles. It falls down sometimes, but I've spent far less time maintaining the infrastructure for my content than I would if I were to build my own blogging engine.
On the other hand, while I don't feel the need for another blogging engine in the world, I definitely see value in what those guys are doing. Specifically, they're building apps, which is not something that XML guys are traditionally into. In fact, I'm scratching my head trying to think of another kind of XML-based technology that isn't infrastructure-based and I'm not coming up with one (even InfoPath is a dev-tool). Is RSS really the first mainstream use of XML that hasn't nothing to do with technology for it's own sake? Are blogs the killer app for XML? I know web services were supposed to fill that role, but while they do solve a real problem, they're not for consumers. My aunt in FLA couldn't make use of a web service. However, she could definitely subscribe to an RSS feed and read up on the local news, her job and her hobbies.
Of course, the beauty of having infrastructure guys building apps is that they get to put into practice what they preach. When stuff is a pain (like every single XML API ever invented and most XML vocabularies), they feel the pain. The difference between us and them is that instead of just wrapping a layer of abstraction around the ugly stuff like we have to, they can actually fix it. I started this piece wanting to shake those guys until they could tell me why they cared so much. How ironic that thinking through the issues in the very medium they're digging into helped me figure out what they were up to. The blog engine work is but the vehicle. They're riding the app train to enlightenment. They're trying to understand how XML can be used to solve problems for real humans. How can I argue with that?
Monday, Apr 14, 2003, 12:00 AM in The Spout
Priceless
- Running sellsbrothers.com for one month: $150
- Round-trip ticket from OR to FL to give a 90-minute talk: $1200
- My son picking me for his "famous person" school report: priceless
I don't know how my son picked up on the tiny bit of fame I've acquired amongst a small, strange (but loveable!) group of people, but he did and now he thinks I'm cool. I'm sure it won't last, but I plan to enjoy it while it does. : )
Friday, Apr 4, 2003, 12:00 AM in The Spout
Oregon & Open Source
Friday, Apr 4, 2003
I had an interesting experience yesterday when I was asked by Mike Sax to come to the Oregon capitol building to testify against HB 2892, known as the Open Source Software for Oregon Act. In general, the bill talks about the benefits of open source, open standards and open data formats, most of which I didn't have any issues with. However, I got up at 6a and drove an hour down to Salem because of the following clause:
"(2) For all new software acquisitions, the person or governing body charged with administering each administrative division of state government, including every department, division, agency, board or commission, without regard to the designation given the entity, shall:
...
(c) Provide justification whenever a proprietary software product is acquired rather than open source software;"
By requiring state government employees to write a special justifications, this bill erects artificial barriers to adopting commercial software, above and beyond the fact that commercial software requires an initial payment (which should be more than enough of an edge for open source software).
If you've never been to a government bill committee hearing, I highly recommend the experience. I was in a little hearing room with a bunch of other folks, all interested in this particular bill. I signed my name on the list of folks "against" the bill so that I would have a chance to testify. The chairman called first proponents of the bill and then opponents up to the microphone three at a time.
Some of the the proponents were teachers and school staff that had put Linux and other open source software to good use in combination with old computers used as thin clients against a back-end server (using X-Windows, I assume). They claimed that they solved themselves all kinds of trouble because open source software was "immune to viruses and security problems" (now *that's* effective propaganda! : ). Some of the proponents were embittered IT staff and new college grads looking to bring some old-fashioned democracy back into a country that had been recently taken over by corporations. It was all I could do to avoid pointing out to them that that the country had been taken over by corporations shortly after Adam Smith wrote "The Wealth of Nations" in 1776 and the budding US government adopted the ideas therein to fund their new country. The basic story of the proponents was that open source was good, so it should be mandated over closed source.
The opponents, on the other hand, were largely suit-wearing fellows from large groups of commercial software corporations (one of which didn't hesitate to remind the esteemed committee that it's member companies had paid $135M in Oregon state taxes last year). Their arguments were that undoubtedly open source software was clearly already being used by government bodies, that there was no rule against it and that their should likewise be no rules against proprietary software. Only Mike, owner of a small Oregon-based software company, and me, owner of nothing at all of interest, represented the "little guy" on the opponent side (we stuck out because of the lack of either a neck tie or a suit coat).
19 copies of my written testimony were submitted without comment at the request of the chairman who assured the audience that all testimony would be read. My verbal testimony was limited to pointing out that shackling proprietary software was "bad engineering" because it could easily cost the state of Oregon more money in the long run; maintaining source code is a lot more difficult than maintaining commercial software for normal humans. I also pointed out that being open source did not prohibit viruses or security problems; the first computer virus ever was written on a Unix, the predecessor to Linux and that they share an identical security model. To be fair, Unix wasn't open source, but I stretched the truth less than the open source guys, so I didn't feel too bad (Unix was "source available" at the very least : ) And finally, I let the committee know that open source didn't mean open standards or open data formats and that, in fact, those were things that commercial software companies had done the most to bring into greater use over the years.
Having never done anything like that before, I wasn't sure how well I'd done, but one of my fellow panelist (a procurement officer from another giant suit-wearing organization) wrote "nice job" on his pad of paper while his colleague preached the wisdom of "amending the language" of the bill to be more "practical."
At the end of the hearing, the chairman of the committee called out some names of the most credible, suit-wearing fellows from each side of the debate to form a working group to come up with a bill that the committee could actually consider submitting for a vote. The sub-text was that the bill as it currently stood was pretty silly; it didn't allow any greater freedom to pick open source software but it did limit the ability to choose proprietary software, which wouldn't make those Oregon software company tax payers happy. This seemed a most sensible conclusion to me and gave me confidence that our government isn't so screwed up after all.
When the room was cleared, I was assaulted by one of the open source proponents, reminding me that Unix wasn't open source and that Linux would never have any such problems (which makes the presence of virus protection software for Linux seem like a very poor business decision). I was also cross-examined by a tall, thin, balding, old-ish man with the longest grey beard I've ever seen in person. He seemed very knowledgeable and was very interested in the details of my opinions. He reminded me of nothing more than a fallen Richard Stallman in 30 years and added to the surreality of the morning.
On the way back to our cars, Mike thanked me for coming and asked if I was glad that I'd come. It surprised me to learn that I was. Not only did I feel that my "just a guy" presence helped the suits make their case, but I felt like I was doing my duty as a citizen. Who knows, this experience might bring out the politician in me. I'm sure I could do at least as well as Jessie Ventura. : )
Thursday, Apr 3, 2003, 12:00 AM in The Spout
Testimony
Chris Sells
Sells Brothers, Inc.
8539 SW 166th Terrace
Beaverton, OR 97007
http://www.sellsbrothers.com
csells@sellsbrothers.com
Oregon State Representatives,
My name is Chris Sells and I run a one-man software consulting firm from my home in Beaverton, Oregon. For more than 20 years, I’ve been pretty much everything you can be in the software world: software engineer, chief architect, director, author, speaker, consultant and even marketer, so I know software ins and outs pretty well. In addition, I’ve been the treasurer for the Cooper Mountain Elementary School for the last two years, so I’m familiar with how important computer-related purchases are to at least one branch of the Oregon state government and how those decisions get made.
Before I start my testimony, I’d like to tell you about my experience in my high schools’s band. I played the trumpet for seven years, four of them in the marching band. I wasn’t great, but I loved to play. It gave me a deep feeling of satisfaction to be part of the band and to perform for the audience. I even continued my playing into one semester of college band, but it just wasn’t the same. The band at that level required a degree of skill and professionalism that I just didn’t have. Once I figured out that I didn’t have what it took to be a professional musician, I went on to find something else to make my living (computers).
By and large, open source software is often very much like a high school band. No one cares about the money. An open source programmer just wants to have their work seen and appreciated, regardless of whether they’re good enough, or thorough enough, to be paid for it.
Sometimes a high school band will be amazing; easily good enough to compete at any level. However, this is very rare when compared to professional bands that get paid based on how well they entertain their audience. Likewise, sometimes open source software achieves the same level of quality as closed source software. In those cases, I?m completely in favor of considering open source software to solve Oregon?s software needs. However, I?m not in favor of mandating open source software, which is what HB 2892 does.By putting up artificial barriers to entry for closed source software, Oregon is narrowing their choices to those rare cases when open source software lives up to the letter of the requirements for a Request for Proposal (RFP) but doesn?t provide the same level of thoroughness that competing for money on the open market requires. This narrowing of choice is going to cost Oregon considerable additional funds in support, training and documentation, all things that the open source community lives without because of their own level of expertise. Continuing the analogy, assembling your own electric guitar if fun for an enthusiast, but requires very specialized skills. Likewise, using, supporting and maintaining open source software requires real engineering skills, which is the hidden cost you don?t see when initially installing open source software.
In addition to mandating open source software, HD 2892 calls for open data exchange standards. This is something that I?m very much in favor of. The latest and most general purpose standard for open data exchange is called the eXtensible Markup Language (XML) and is fully embraced by both the open source and the closed source communities. However, it?s the closed source vendors, like Microsoft, IBM and BEA, that are really making XML a reality by pushing it into their software at all levels. In fact, these same closed source vendors as going beyond just XML and building standards for communicating data between computers based on open source and closed source operating systems to make sure that all computers can communicate with each other. These standards are called ?web services? and are based around the Simple Object Access Protocol (SOAP). Defining, implementing and testing standards is an expensive proposition involving man-decades of dedicated engineering work, which is why it takes companies that make money on software to turn them from an adolescent dream into an adult reality.
I believe that open source should absolutely be considered for the state’s software needs. However, being open source is but one quality that needs consideration. Things that also need to be considered include the cost of training, documentation, support, upgrading and maintaining software systems and their support for open data standards. Some open source software will achieve the level of functionality and attention to detail that Oregon needs, but artificially narrowing your choices to open source software is like open picking high school bands to play at the Rose Garden. Sometimes you’ll get lucky but more often the audience is going to demand a refund.
Thank you for your time and attention,
Chris Sells
Tuesday, Feb 18, 2003, 12:00 AM in The Spout
Microsoft & Patents
Tue, Feb 18, 2003
The buzz was all around VSLive last week about Microsoft patenting the .NET Framework API. In fact, an eWEEK reporter asked my opinion and this is what I said:
I'm no patent attorney, but in examining the patent application, it looks to me as if they're claiming a patent for the entire .NET Framework, which comprises the classes that a .NET programmers uses to get anything done. My understanding of the patent laws says that Microsoft has every right to do this, since they invented it. The reason for them to do this is so that they can maintain control of its implementation. Hopefully Microsoft will grant a royalty free license to all implementations of the CLI ECMA standard, which makes up a large percentage of the .NET Framework, or that standard will be worthless.
Even if they grant such a license, projects like Mono are still vulnerable. They plan on implementing even the parts of .NET that aren't standardized, like ASP.NET and WinForms. This would allow Windows programs compiled against .NET to run under Mono on Linux, providing a single API for cross-platform applications. This has been tried and failed in the past as recently as Java, but I had hoped that the Mono guys could make this work. When Microsoft is granted this patent, they can shut down the non-standardized parts of Mono whenever they want. That's good for Microsoft share holders, but it's not good for 3rd party developers that want to write cross-platform solutions.
What I should have added is that as far as I know, Microsoft hasn't ever enforced its patents. Apparently they keep them for defensive reasons only. Or, they could be waiting 'til they have a critical mass of patents, enforce them all at once and win the game of Risk that they're playing with the world. : )
Friday, Feb 7, 2003, 12:00 AM in The Spout
Saving Your Career
Friday, Feb 7, 2003
In response to Never Send An Email In Anger, Lars Bergstrom recommended that I set up a rule that defers sending an email for 1 minute. I set it for 2 minutes under Outlook XP like so:
- Tools->Rules Wizard
- New
- Start From A Blank Rule
- Check messages after sending
- Which condition(s) do you want to check? -> None
- This rule will be applied to every message you send. Is this correct? -> Yes
- What do you want to do with this message? -> defer delivery by a number of minutes
- a number of minutes -> 2
- Finish
And it works like a charm. It's always w/in the first second that I wish I could recall a message, so two minutes should be more than enough. Wahoo!
Monday, Feb 3, 2003, 12:00 AM in The Spout
Let The Language Wars Continue
A friend of mine pointed out to me the other day that the C in CLR stood for "Common," that is, the CLR provides the same services to all languages. In fact, at this date, C# and VB.NET are really just "skins" over the CLR and provide nearly identical functionality. With that in mind, why are we still fighting the language wars? There are several reasons:
- VB and
C# programmers are just culturally different. They come from different
backgrounds, different educations and different points of view. Remember
that VB was initially invented to let non-programmers program. C++
programmers came from folks building operating systems. Those roots are
still evident today.
- The VB and C# product teams are
different and gain benefits based on how many of each kind of programmer
there are. Based on that, do you think that those teams are going to pound
the "all languages work great under the CLR" or the "C#/C++/VB.NET rocks"
drum? Which message makes you look best at review-time?
- Languages *should* be different. Managed C++ does that cool managed code/unmanaged types thing. Eiffel# does Design by Contract. Perl.NET has obfuscation built in at the source code level, alleviating the need for a 3rd party tool. The fact that VB and C# are virtual clones of each other is a mistake that I hope is rectified. Frankly, I hope that VB goes back to it's roots of enabling non-programmers, as that's a huge hole in the current list of managed languages. Certainly C# is going back to its roots by adding generics et al in the next version.
I've found that the "Common" means that teams can use the same language at more levels of their system, i.e. no more VB for this, C++ for that, script for this other thing. Now it can be all VB or all C# (or almost all, 'til Yukon ships) and the number of different kinds of programmers needed for a single project goes down. That provides a real benefit to companies trying to keep costs down and quality up while still allowing the team to decide what language features are important to them. This is goodness.
With the increased shared capability at the runtime level, I'm actually hoping that language motivation will increase. I think that there's still a lot left to do to make the programmers more productive and the motivation for one language to gain ground over another is a good thing. Plus, I still have an excuse to make fun of semi-colon-challenged programmers and what could be better than that? : )
Friday, Jan 24, 2003, 12:00 AM in The Spout
OOD (The D Stands for "Dead In The Water")
Reading a very interesting book which I'll discuss in a future post, I came to a startling conclusion. As much as I love OO thinking and programming, OO databases are never going to fly. I realize that this may not be so startling considering how long OOD products have existed and how unsuccessful they've been so far, but the conclusion I came to was *why* they'll never fly. The reason is simple: the data itself is more valuable than the programs that use it.
For an OO guy, taught that behavior was everything and data was an implementation technique, that's a startling conclusion. However, the beauty of a database is that it's devoid of behavior, or, if there is behavior, it's layered in on top of the data. Programming languages come and go along with the ideas that underlie them and the applications that are built with them. Relational data, on the other hand, is a model that's simple enough, but complete enough, to move forward from application to application, accumulating value as you go in the data itself. And, since the relational model is so entrenched, no technology for the last 10 years or the next 1000 would be complete without support for it. Even Microsoft, IBM, GM and AT&T will prove to be less enduring than relational data, the tools to program against it and the tools to slice and dice it w/o programming anything (the latter are amazing strong already and continue to grow).
Data in OO databases, on the other hand, are bound to behavior and worthless for anything but the limited set of applications for whom the behavior was paramount and the data an implementation detail. When things change, as they always do, how are you going to get the data out so you can do things different? You're going to dump it to the simplest, most complete, most firmly entrenched data format that the world has every known -- relational data.
OO persistence formats are, by their natural, tied to a specific object model and therefore hopelessly proprietary. And with the emergence of XML, OO persistence formats are going the way of the dodo, even for applications running on machines without a database server. Why would I persist data to a closed format when I can choose relational data for the big stuff and XML for the small stuff? Both provide endless tools for slicing and dicing and bringing forward when the application dies. With OO persistence, when the app goes, so goes the data. The problem with OOD is that things are *too* seamlessly integrated. Ironic, no?
Thursday, Jan 23, 2003, 12:00 AM in The Spout
Sealed Sucks
I've come to the conclusion that the use of the "sealed" keyword in C# (and the concept in .NET) should almost never be used, at least on a class. Semantically, sealed applied to a class means that a class cannot be used as a base class. For example, the ImageList class from the System.Windows.Forms namespace is sealed:
public
sealed class System.Windows.Forms.ImageList : ... { ... }What sealed means is that the designers of the ImageList class didn't take the time to test what would happen in all the scenarios where an ImageList is specified but a subclass is provided, e.g. MyImageListEx2. So, since they didn't test these scenarios, they're protecting developers from deriving from the ImageList base class when bad things might happen. They're also protecting developers if the base class changes radically in the future and derived classes no longer work.
Stop it!
I don't want to be protected in this way! Instead, I want to try to derive from ImageList and see if it works in the scenarios in which I'm interested. And if future versions of the ImageList base class break my derived class, I want to update my derived class in ways that work across versions of the base class or have two versions or whatever else I need to do to make it work. By making a class sealed, I just don't have any choice in the matter, which severely limits me in what I can do.
As an example, I think that the current ImageList implementation sucks in the following ways:
- Every time you need to edit an image, you need to remove the old image and add it back again
- Images are too small to see what they are
- Can't tag images with names
So, I'd like to build my own ImageList implementation that has the exact same programmatic interface, but that pulls images from manifest resources, fixing most of the issues above. All of the controls that take images get them from an ImageList type, so I need to provide my extra functionality in a type that's compatible with ImageList. However, the only way to do that in .NET is via inheritance and the damn sealed attribute disables my ability to do that! Instead, I have to build a custom component that's also an extender provider if I want to provide the same design-time usage as an ImageList and I have to tell developers using my image list component not to use any of the ImageList-related properties because it will conflict with mine. I literally can't package my functionality in a way that's developer-friendly in the same way as the ImageList and it's all because it's *sealed*!
Of course, the ImageList class isn't the only one. I had a solution to the problem of asynchronous method calls to web services from WinForms apps the other day (the problem is that an extra hop is always required to get back to the UI thread), but my solution can't work because the base delegate type required to make an asynch call is sealed. And the list goes on and on of things that I can't do because somebody is "protected" me from potential bad things.
Please, please, please, please, please don't mark your classes sealed. If you do, folks that want to provide extended functionality, and test to make sure that it works the way it's supposed to, don't even have the option. Type compatibility is a huge deal when you're dealing with class-based abstractions instead of interface-based abstractions and using the sealed keyword throws all of that away. The C++ community survived very nicely without sealed for a decade and it's made half of the classes on my site possible.
You took away my deterministic finalization. Must you also take away my ability to derive?
Wednesday, Jan 8, 2003, 12:00 AM in The Spout
New Year's Resolution
I just flew in from 2002:
- Wrote or co-wrote 4 books: Mastering VS.NET, Windows Forms for C# Programmers, Windows Forms for VB.NET Programmers and ATL Internals, 2/e (you should see them all in 1H03)
- Helped Don & Shawn with their books (no writing, just heavy-duty feedback)
- Wrote 6 articles for the Wonders of Windows Forms column (some are excerpts from my WinForms book)
- Wrote 9 articles for the "Chris Sells on .NET" newsletter (some are excerpts from my WinForms book)
- Started the "Adding Ref-Counting to Rotor" research project (we've got a alpha running!)
- Wrote a 5-day WinForms short course
- Spoke at bunches of conferences and seminars, including the 2 Web Services DevCons I hosted
- Started a newsletter and published 8 issues
- Started the Windows Developer News forum
- Wrote or co-wrote 13 magazine articles (3 are still pending publication)
- Wrote 29 Spout pieces, including the ever popular VS.NET Fun Facts
- Shipped 3 releases of Genghis
- Shipped several other new tools and samples, including Wahoo!, CollectionGen, XsdClassesGen, imcli and RegexDesigner.NET
- Created the Intel Rich Client series where I served as the editor for 6 articles (1 is still pending)
- Consulted for several companies
- Mentored several proteges
- Conducted a very painful, but very fruitful, marketing survey
- Lost 55 pounds (which I hope never to find again!)
- Answered countless mailing list and direct questions via email
and boy are my arms tired! Even I look at that list and think "holy workaholic, Batman!" Of course, I couldn't have done all these things alone. I worked with fabulous co-authors and co-contributors. Thanks to you all and I look forward to working with you again in 2003!
In the new year, I have the following goals:
- Make Ask The Wonk a fun experience for all involved (it just started on Monday, but it's already great fun answering the level of questions I've received!)
- Move the DevCons to the phones via the PhoneCons to avoid the expense and hassle of travel for everyone, while still maintain the power and charm of the DevCon
- Get those .NET War Colleges humming! I *so* look forward to these
- Several more releases of Genghis (a new release is already cooking)
- A few more magazine articles (I've got a few already in the queue)
- Finishing up the Rotor ref-counting project, publishing the code and the results
- Re-org the web site a bit (again!)
- Continuing the Wonder of Windows Forms column
- Hanging on the Off Topic mailing list (still my favorite mailing list)
- A couple of other projects that I'm dying to share with folks, but am sworn to secrecy...
- Losing another 35 pounds (it's a 2-year plan)
- Find a way to take a vacation
We'll see how I do this time next year, especially on those last two.
Thursday, Jan 2, 2003, 12:00 AM in The Spout
Apps Are People, Too
I concerned Wahoo! patron sent in the following screen shot of the current high scores as exposed by the high scores service:
As you can see, the high scores service has turned into the poster child for the need for web service security. However, after hanging out at two Web Services DevCons and talking with Keith "Mr. Security" Brown, I've come to the conclusion that there is no good way to secure this specific web service. Even worse than that, there's an entire class of web services just like it that can't be guaranteed secure.
The goal of the high scores web service is to provide access only to the Wahoo! app itself. Only Wahoo! knows when someone has earned their score while playing instead of merely faked it through some other means. Of course, this application is just for fun, so the lack of a secure high scores repository is hardly a big deal (although I'm often surprised when people tell me that they play wahoo.exe instead of sol.exe). However, imagine that a real application wanted to do the same thing. Maybe Microsoft only wants Office applications and not Linux knock-offs to query the clip art web service on microsoft.com. Or maybe your business wants to provide a web service that only your apps can talk to.
Of course, Microsoft doesn't ship the source code for Word and your business is unlikely to ship the source code for your apps if you plan on making money on them (remember actually making money on software?), so that's different than Wahoo!, isn't it? No. Every time you put code on a machine outside of your sphere of influence, you might as well ship code, especially if it's .NET code, which comes with a built-in disassembler! "But wait," you say. "What about code obfuscators?" Well, that arms race has already been fought in the world of Java and disassemblers won. There was no way that an obfuscator can hide the details of Java byte code without completely destroying the usability of the code (particularly in the area of performance). .NET will be no different.
"Aha! But what about unmanaged code? x86 can't be read like IL." You're right. It is harder to disassemble x86 than IL, but not significantly so. The x86 disassembler tool vendors have been working for a lot longer on this problem and we've bred guys like Andrew Shulman and Matt Peitrek that dream in x86 and only translate to English as a convenience for their wives.
The bottom line that if you ship code, you might as well ship the source, as it's available anyway. If a computer can execute your code, somebody can read it and pull out the details of whatever you're using to obfuscate the communication between your code and your back end (whether it's a web service or not).
"So why do I have to log in all the time if there's no such thing as security?" Well, it's not as if there aren't ways to secure systems in the world, but all working security thus far invented depends on physical security, whether it's the private part of a key pair secured in your safe or a password secured in your brain. The reason that applications can't make use of this kind of security is because they don't have access to safes and their minds can be read much more easily that those of humans (although a rubber hose is just as effective as ildasm.exe, when something is really important).
So what does that mean for applications that want to make use of back-ends? I see four solutions. One, you can tie security to a user instead of an application. For example, if I make everyone sign up for a Wahoo! account to log high scores, I'd at least know who to ban from use when they faked impossibly high scores. However, it also opens up the possibility of the user completely bypassing the application altogether, including any checks that the client may make on validity of the data being sent to the back-end.
The second possibility is to make things hard*er* on the potential hackers. Keith summed it up nicely:
"After looking at your JPG, I'd suggest some server side filtering. Limits on user name length and content would help you at least reduce the amount of space that hackers can use for advertising. OTOH, you've got a nice little bulletin board going there ;-)"
Anything I do in the way of encryption and obfuscation between the app and the back-end will slow down potential hackers and for something like Wahoo!, I don't suspect it would take much to keep folks honest (turning off the asmx test page would be a good first step, for example : ).
One way to make things harder, and a third way to secure apps, is a dongle, which adds new hardware to a machine along with the software. Unfortunately, a dongle could be reverse engineered just as a hunk of software. It's only the fairly uncommon use of dongles that keeps them from being broken more often.
The fourth option, which Keith mentioned, is Microsoft's new Palladium platform, which operates with special hardware and software to limit a user's access to their own computer, kind of like a universal dongle.
The real question is, what's secure enough? Unfortunately, this is an arms race that will eventually be won by any hacker with enough smarts, time and money. For users, we continue to make things harder on hackers as we transition from passwords to biometrics and smart cards. For applications, we've got dongles and precious little else, which makes it darn hard to treat apps like the independent entities into which they're evolving.
Friday, Dec 20, 2002, 12:00 AM in The Spout
Keep On Cookin'
I got a very nice email today from Ross Lambert:
"I'm a new fan of yours, both in terms of your technical abilities and the down-home honesty of your columns in The Spout. I loved 'Of Eggs and Omelets', mostly because I could identify with it. My own career has been littered with a lot of broken eggs. I ran my own little software company for nearly 10 years, writing and selling developer libraries for Macintosh developers. Needless to say, the ups and downs of that market were fairly impossible to survive.
So now I am enjoying the Dark Side, as Mac folks would say. I'm a total .NET-head, hence my fairly recent acquaintance with your work.
Anyway, all that to say 'Don't let the turkeys get you down.' I was a pretty decent marketer; I still write ad copy for different folks from time to time. It was the only way I could manage to survive as long as I did. For what it is worth, I think your approach is innovative and fun. A few anal people will object (it sounds like they already have), but I've come to the conclusion that about 2% of the population actually enjoys being uptight and offering angry complaints. You'll never make those folks happy, and it is just as well to give them a reason to bail out early in the game."
Thanks for that, Ross. While Of Eggs and Omelets speaks of breaking eggs as metaphor for the negative feedback I've gotten from my recent series of marketing-related emails, in truth only a tiny fraction of folks complained. In fact, almost 10% of my newsletter subscribers responded to my inquires in some positive way, which is about 50x the number of people that had something negative to say. According to the marketing guy, getting a 10% response was about 3x what he was hoping for (although he didn't tell me his expectations until *after* the results were in... : ). Even more telling was the large number of people that actually thanked us for asking. Apparently expressing interest in their wants and needs was unique for a surprising number of people. Further, the shear number of people interested in the various ideas we proposed (like the .NET War College and the WinForms PhoneCon) was only overshadowed by the number of people with good ideas that we didn't even think of (which is what lead to Ask The Wonk).
So, while I may have broken some eggs, and every one of those emails physically pained me (how do spammers do it?!?), Ross and tons of others have encouraged me to keep on making my omelet.