First, some random stuff. I got a free t-shirt from Newegg yesterday and I didn't even have to buy anything! It turns out that scammers have been using Newegg's domain in phishing attacks. As I was reading through this, I thought to myself: isn't there some way to counter this? I came up with a pretty simple solution and emailed it to Newegg's customer service email: why not just have all account holders, when they enter their information, also enter three code words -- for example: "Apple", "Frankie", and "Coolio" -- and from that point on, any correspondence would include one of these three words, selected at random, in the subject line. This way, a customer can easily scan emails which appear to be coming from Newegg and tell which ones are spam and filters can also be set up to simply remove anything from Newegg that doesn't contain one of the code words in the title.
There would be no way for a scammer to overcome this without knowing the codewords (yes, I did think about it for a while and one codeword would probably work just as well since if you compromise even one, you've compromised the effectiveness of the entire system).
So simple (simple to program, simple for customers), yet so effective...I like simple things.
On another front, I've been working on a consulting project kind of indepenently with a development team in a primarily Java environment. I've been doing some really nifty UI work and the sort of cutting edge web software that I love to do (I know you can't tell by this webpage and I know his blog is displaying incorrectly in IE7).
Since I first came across AJAX, it has always been in my mind that, given this tool (a gift from the web programming gods, I tell you), the ideal way to write web apps goes sooo far beyond what any server web application platform can offer. Perhaps some view this as a bit radical, but I have proposed that the application server be completely oblivious to the existance of any UI at all; all functionality is exposed as a web service and it is then up to the consumer of those services to decide what to do with it. What exactly does this mean? The server delivers what is essentially a base HTML page and from that point on, the server side app has no further involvement in the UI. All of the rendering is then accomplished by client side scripts through DOM manipulation.
This has HUGE advantages over traditional postback/getback models.
- The rendering script can be cached. That means that while you may bulk up on the scripts, you end up saving a HUGE chunk of bandwidth on not delivering highly redundant HTML. Using this model, you only ever deliver data, NEVER delivering UI markup.
- The design is incredibly clean on the server side. None of this intertwining of UI postback handling and layout garbage. The application is responsible for providing data services and data services only. This is a win-win situation as it does not ask the application programmer to build UI (something which most are terribly incompetant at). At the same time, given a base set of messages, the UI developer can start working on client side code immediately with mocked up messages.
- The application is highly reusable now. The same web services powering the web application can be retooled a bit to power ANY client.
- It offers a better user experience. This is true for any usage of AJAX.
- It offers a clean separation of concerns for the two domains of the application: the UI and the server components. Completely clean. No half-assed distinction as with ASP.Net and ASP.Net controls. There is no concept of UI at the server side -- NONE -- only data.
I can't be the only one that believes in this, can I?
But in any case, I'm really down on out-of-the-box ASP.Net and I'm really down on people that adhere to it because it's easy (don't get me wrong, I love .Net). It all goes back to the drag-&-drop mentality. I abhor this approach to software. When something goes wrong, developers that adhere to this philosophy are like deer in headlights. Source is your friend. Get to know Source. It'll be good for you in the long run.
Nothing against Infragistics, but has anyone seen the HTML source produced by their ASP.Net controls? Wow. Fugly beyond belief and HEAVY to boot (the same is true of SharePoint...it's unbelievable). Not only that, the markup in the page is horrendous and completely illegible...how do they stay in business? Oh yeah, the gigantic cadre of drag-&-drop professionals brought up in the drag-&-drop era. They've sold the idea that these controls save time and money while I would argue that the time & money saved is not that significant it since it leads to hard to maintain code, heavy markup delivered to the client, "cookie" cutter UIs that tend to look alike (even across organizational and business boundaries), and a lack of tailoring to the users. I mean, it may save what? a few hours of development time? But you end up with code that is incredibly heavy, hard to read, and hard to maintain. It's time for server side UI to die. Completely.
Oh yeah, we're kicking it up with the DevTool entries.
That's typically what happens as I ramp up on a project; I'll end up coming across a whole slew of awesome tools that I end up aggregating in my C:\Program Files directory (my application menu is about to go past the second page...I had to uninstall a lot of stuff previously to get it back down to two pages).
Today's entries are tools to help you think "contract first". I hadn't really thought of XsdObjectGen.exe as a tool that helped you work in a contract first fashion, but Peter Bromberg seems to think so and so does David Truxall.
Unfortunately, XsdObjectGen.exe, as great as it was, is ill suited for .Net 2.0 and the introduction of generic types and lists. I briefly contemplated using it for my .Net 2.0 project that I'm on now, but couldn't bring myself to it; there must be a better way, right? Well, up until now, the only other .Net solution that I had come across was Matias Wozloski's GAT implementation (with slight modification?) of Daniel Cazzulino's (kzu) version of XsdObjectGen. Having looked at that and the new xsd.exe that ships with VS2005, I have to say that I'm sorely disappointed in both since they rely on the XmlSchemaImporter and XmlCodeExporter classes to do their dirty work. The resultant markup is not nearly as nice as the output from XsdObjectGen.exe. As I've mentioned in the past (see the end of my workshop on XsdObjectGen.exe), while kzu's implementation is obviously much more flexibile since you can create new extensions and what not, it is ultimately somewhat clunky and not as easy to work with.
I briefly contemplated extracting the source from XsdObjectGen.exe and rewriting the codebase (it uses sort of an "intelligent templating" approach) to utilize some of the .Net 2.0 code features and generate better code, but after digging through it with Reflector, I realized I didn't have enough time (and I probably didn't have the rights) to extract and rewrite the codebase.
Enter dingo and thinktecture's WSCF. While dingo is still strictly a .Net 1.1 tool, the project leader has a recent news item that claims forward development will continue this summer after some more work on a rules engine (anyone know of .Net APIs for working with RuleML?). WSCF, on the other hand, looks like it's good to go with respect to .Net 2.0.
So have a look at WSCF. I'll be downloading and evaluating it today and keep this updated with my take on it.
Update: See comments.
I going to have to take a look at this Composite UI Application Block from Microsoft's patterns and practices group.
It actually looks very similar (at least from a 10k foot view) to the architecture/design implemented by Omar Al Zabir in a writeup over at CodeProject.
I admit, I've never been much of a WinForms guy, as development of Windows clients has never really interested me (partially because of what a pain in the ass it is to work with WinForms compared to WebForms (XHTML markup just makes more sense for UI layout and presentation, at least in my opinion)), but I think it's probably worth my time to take a good look.
Having been a consultant for the last few years, I've been in many organizations, seen many application architectures, and met many developers. What saddens me is that far too few developers/consultants in the Microsoft space are digging the Patterns & Practices group in Microsoft. To a large extent, I think this issue is directly tied to how "easy" Microsoft has made the .Net development process. Certainly, it's quite easy to learn .Net, especially with the visual designers and drag-and-drop controls, but to write an enterprise application involves quite a bit more than building some of the samples out of a book and calling it a day.
I've consistently found that companies will continue to roll their own data access layers simply out of ignorance. Ignorance of the Enterprise Library, which is designed to be pretty much plug and play in so far as providing some infrastructure to common application needs. The case for Enterprise Library is fairly straight forward, in my opinion, but I'm amazed that so few developers I've come across actually know what it is and how to properly utilize (or even at least offer some alternatives (I myself prefer log4net for logging, but it's generally tougher to get companies to use open source projects vs. Microsoft products)). But even aside from Enterprise Library, there are a number of great solutions to the common problem of data acccess, including NHibernate and EntitySpaces (formerly dOOdads). While certainly, uptake and acceptance of third party solutions should expectedly be low, there's no reason why developers are not utilizing Enterprise library, aside from ignorance, NBH (Not Built Here) syndrome, and arrogance ("I can do it better"). This isn't to say that there is never the case for rolling your own solution, but you better make damn sure that you can come up with a convincing argument other than the three just listed.
On a more fundamental level, while .Net is generally considered a far more productive framework to utilize, as compared to Java or unmanaged code, it is also a lazier lanaguage that requires the developer to know less about architecture and designing software solutions. Combined with Microsoft's history with classic ASP and VB6, you end up with a lot of ".Net developers" who continue to write VB6 style applications and only use classes to demarcate the boundaries for a function set. There is a tremendous lack of understanding of object oriented programming concepts in almost every single organization I've worked with (with the lone exception being Factiva, where two of the developers in my group were really top notch). Seriously, ask some developers what the C# keywords abstract, virtual, and interface mean and you are guaranteed to get either looks of bewilderment or some off the wall answers.
This frustrates me to no end; my mind simply cannot handle this type of development. I've always been fond of the saying: "Never wrestle with pigs. You both get dirty, and the pig likes it." I feel an obligation to myself and, more importantly, to an organization that's paying for my services, to introduce standard practices, design patterns, solutions, and libraries where appropriate. I think this has gotten me into trouble on more than one occassion, including my current situation. I mean, 12 months ago, the idea of unit tests (as in NUnit) were lost on me. I didn't really understand the value of writing these tests and how to properly utilize them. I still do not feel that I'm solid on the latter, but I've definitely come to appreciate the value of unit tests and using a test driven approach to implementing code. I simply cannot write un-tested code nowadays as I find it inefficient and unprofessional. And yet, clients neither understand nor appreciate what it means to take a test driven approach. Instead, this type of development is actually discouraged as the front-loaded work is typically very far from the UI (at the class library level), which means that the business people and managers don't feel progress. I mean, I can feel it in their eyes when they look at me and wonder what I've been doing and why I haven't hacked together that WinForm yet.
Seriously, is there something wrong with me? Am I just being snobbish about this? I like to think not, as I openly admit that I myself underestimated the value and power of a test driven approach just 12-14 months ago and I've since undertaken the task of adopting it as SOP. But the thing is, very few developers, at least that I've worked with, take the initiative to learn technologies and software engineering practices beyond learning the base .Net framework. Mind you, I'm not talking about small time consultants with small companies. I'm taking about $150+/hr consultants working for multi-billion dollar companies. But then again, a lot of these consultants are not really in consulting positions; more accurately, they are really staff supplements, which typically puts them into a weaker position in terms of affecting change (myself included; this is what I really hate about so called consulting gigs, no one really wants to consult you on anything, they just want you to sit your ass down and write some code....now).
Enough ranting I guess. Understand that I'm not trying to come across as elitist in any sense; I simply expect developers to remain active in learning their discipline. I expect architects and consultants to understand the technologies in the relevant solution space before sending the devlopers off to write the code. I simply expect people to be educated and open to ideas, especially people in a technical lead role. In any case, Enterprise Library for .Net 2.0 is upon us. I'm actually fairly excited to put it to use and see how the team has improved upon the existing library. It's worth checking out Tom Hollander's blog (Microsoft's product manager for Enterprise Library (Yes, it's a full time project within Microsoft staffed by real life Microsoft employees)) for some of the dirt on the new features and changes in Enterprise Library for .Net 2.0.
On a closing note, I'd just like to make an observation. It always amazes me when I see people's desks with stacks of books that were obviously never touched. It's as if some developers think that they can learn by osmosis...keep that C# book close enough, and some of that info might just magically seep into your brain. I only wish it were so easy.
Perhaps even that is too weak a word.
Omar Al Zabir demonstrates an amazing breadth and depth of understanding of many technologies in addition to sound software engineering and design concepts.
He has a great writeup at CodeProject. That just blows me away in the elegance of the design and the way that he's able to have such a deep grasp of so many of the technologies that are relevant.
From time to time, as I'm working on projects, I invariably come across great sets of tools that make my life just a bit easier. My plan is to list the tools, test them out, and rate them somehow after I get some usage. I guess this is my way of sharing with the world
So for the inaugural entry, we have two tools and one library:
- FaceID Browser. When creating custom add-ins for Office applications, you can create a command bar button (CommandBarButton) and apply an existing Office icon using the FaceID property. This tool allows you to visually map the integer values to the icons. I've tested it to work with Office 2003.
- Xsd Generator with GAT. For some reason or another, I like the idea of working with XML schemas when building an object model; schemas seem much more natural to me than working with classes in code. In addition, you get nice XML serialization markup for free Matias Woloski has written a custom generator for .Net 2.0. I'm gonna give it a look-see. [Update:1] The binaries that are currently on the GDN website are not compatible with the RTM versions of VS2005. [Update:2] Holy crap. After several hours of fiddling, I finally got it to install. Damn, the December CTP of GAT extensions is still buggy as hell. For some reason or another, uninstalling the Xsd Generator after installing it would also remove all traces of the Microsoft.Practices.RecipeFramework dlls. WTF? So this would necessitate reinstalling the GAT extensions. On top of that, the December CTP changed the default namespace on the configuration file from http://schemas.microsoft.com/pag/ipg-core to http://schemas.microsoft.com/pag/gax-core took me at least a half an hour of digging to find this info. The other really stupid thing is that you can't change the config file after install without reinstalling...another big WTF; I mean, isn't that the whole point of having an XML config file? I also had to rebuild the references in two of the projects and add a missing reference to Microsoft.RecipeFramework.Common.Library. But in the end, it's worth the effort! I dig the fact that it generates generic lists instead of typed collections (typed collections are soo last gen. :-D).
- Microsoft Updater Application Block. Looks useful for anyone currently building lots of application add-ins for any of the Office applications as it will allow you to keep clients up-to-date without having to redeploy with each update. There's an article over at TheServerSide.Net on usage and details.
That's it for now. Look for more installments in the future.
A blog post I came across should be of interest to anyone working with AJAX:
Add this small script to your page (preferably in the <head>
section) and all your XmlHttp requests will be done synchronously no
matter what the framework you're using is doing. This works with ASP.NET
2.0 callbacks in both IE and Firefox but breaks callbacks for Opera. I
suspect that it would also work with other Ajax frameworks such as Atlas.
Supposedly, this will work with any AJAX framework. I've been running into just this issue with AJAX.Net. Having used both AJAX.Net and Atlas somewhat extensively, I'll have to give the edge to Atlas for pure ease of use.
Wow, I had a lot more fun in Philly than I thought I would have.
Back up a bit. I had originally registered for the Microsoft launch event in Philly as a participant a few weeks back. Last week, Rich, my new manager, got 4 of us together, the only 4 that had really played around with SQL Server 2005, and asked if we could come up with a demo for the show as, apparently, we had a presence at the show.
Long story short, I ended up taking up part of the responsibility of building the demo and also working the booth at the show. Somehow, we ended up building a database mirroring demo which featured an ASP.Net 2.0 and Atlas frontend.
I also ended up with the responsibility of creating some posters and datasheets that we could hand out along with our demo. Keep in mind that all of this came up last Thursday. Having technical and graphical skills is both a curse and a blessing I guess.
Well, in any case, the show was a huge success. We had people lining up to look at the demo and to talk to Igor and myself. For an app that was put together in 10-12 hours, it was surprisingly stable. We only had one major issue and that was a networking issue (dropped IP addresses). It was so good that we had people coming back to the booth after seeing the datasheet from other people. We had people coming back with their friends because they were so impressed. It was quite amazing. We ran out of the datasheets for the demo in the first 90 minutes of the show (maybe the first 60). Fortunately, we also had it in poster form (which we didn't give away). It drew quite a bit of attention and there were a lot of people who just stopped in their tracks to check it out. The funny story regarding that is I almost didn't have the poster printed. I was originally only going to print 8.5x11 copies, but Frank, another consultant, suggested that I go with the poster.
Believe it or not, I put it together in ~3-4 hours Tuesday night after I got back from a client site. Everything on this sheet was created from scratch (Except for the computer graphic, which came from Visio). I swear I was half asleep when I put it all together
I actually heard a lot of comments on the poster, even one from a professor who said she really loved the layout and colors. Even my wife was impressed that I put this together when I did/in the amount of time that I did it in.
So all in all, a fun but tiring day. Man, I just love building cool stuff and I love connecting with other developers. Hopefully, I'll have more opportunities like this in the future.
I'm not only going as a participant, but a small group of us will be there representing EMC, one of Microsoft's partners for the event. Rich Millman, my current MC, will be on some speaking panel and a couple of us will be manning a booth on the floor.
As there were only 4 of us in the group at INS Piscataway that have played around with and read up on SQL Server 2005, I was invited into a brainstorming session on what type of demo that we could put together that would draw people in and hopefully get some new contacts.
My first thought was to create a failover cluster using 4 spare PCs that we had. Not that it's a great demo of the new features of SQL Server 2005, but I figured that it would draw people's attention and since most developers probably very rarely interact with failover clusters. It would have been cool to let people walk up and plug/unplug indivitual nodes and watch it failover automatically. Alas, we didn't have any spare hardware sitting around to build the disk array and it was probably too late to borrow anything from EMC.
My second idea was a little better. Even though database mirroring isn't officially supported in this release of SQL Server 2005, I figured it would be cool to demonstrate it as it's much more likely to be used than failover clustering due to the low cost of implementation. And so, myself and Igor went about building a demo setup for database mirroring.
One of the first challenges we had to overcome was to figure out why it's not officially supported in this release. Obviously, it would have sucked to spend hours working on the architecture and UI only to realize that mirroring was buggy and unstable. After some research, it turns out that the primary reason for not supporting it in this release is because of the fact that Microsoft couldn't find enough beta testers to fully test the new feature. With that in mind, we decided we could probably pull it off and Igor and I started to dig in.
It's actually fairly cool and takes advantage of a lot of the new features of the 2005 suite. The UI is an ASP.Net application that utilizes Atlas to retrieve data from a web service. Another web service was written to interact with the host machine services to stop and start the individual SQL Server instances. Very cool. I'm hoping I can talk them into letting me post the code and walkthrough here for anyone that wants to try to set up mirroing.
So if you're going to be in Philly at the launch event, look for INS there! The demo is very cool.
I hate to just link to pages, but there's a lot of stuff to catch up
on today, so allow me to indulge myself by placing a little reminder
Lance offers a small take on the ever present challenge of staying relevant and educated.
That's it for now; got lots of reading to do tonight.