June 2003 - Posts
My employer pays me to provide applications from start to finish, and in a short period of time. To me my current work environment (the most stimulating environment and best employer I will probably ever have, btw) has always been about productivity: how much software in how little time. I've been working strictly as a telecommuter for 3 years now, so the productivity aspect is even more the defining characteristic of my work day (work night, work weekend, whatever.)
To stay productive and putting out applications for my company, I don't have the luxury to explore the underlying technology behind the code I write, I can't walk through the ASP.NET Starter Kits as I would like or study the new MSDN Application Blocks from start to finish. I'm not complaining at all. Like many (I'd bet to say most) developers, my learning and investigations must focus on the code I am writing TODAY. Learning is done in very specific areas to get the job done, hopefully gain understanding along the way, add a source for future reference, then move on--back to the project and the next issue.
So the focus of the weekend was on xpath queries, with namespaces, and secondarily, the display of those queries. I've used xpath "to get the job done" on several occasions but recognized the need to study outside of the app for a bit. This is where Wrox's Professional ASP.NET XML with C# comes in. (Pic top right.) I've read 4 books on XML and (the most recent being Dino Esposito's Applied XML Programming for Microsoft .NET) and this one was by far the most code-focused. I was able to use its Xpath sample and customize it as a generic Xpath tool when I need it for quick testing and study. (Original at right middle, customized version at right bottom.) I learned a few things since yesterday and my xpath comfort level with namespaces has increased.
Sidebar: don't get me wrong about the Starter Kits, Applications Blocks, and other broader scale learning tools I didn't mention here. I'm spending two weeks in a beachfront house in North Carolina in a few weeks and am planning on loading up a few of these bad boys on my laptop for vacation pleasure reading. Other beach study recommendations welcome.
Posts about blogging from a pedestrian like myself (as opposed to the top-shelf shakers who are enhancing the spec) reminds me of when I was a young buck with girlfriends who seemed to always want to talk about the relationship. Now I am happy to just BE in a relationship with my wife and enjoy all those things which a relationship brings.
But it was time I talked about blogging to my forward-thinking Company President. I put together a PDF position paper, of sorts, 4 pages long (mostly bullet lists, bibliography, and illustrations) with a brief description of blogging, a list of Corporate Benefits, and description of how weblogs are read and authored. (Yes, there are many ways of consuming and generating weblogs, but that would have detracted from the paper's objective.) To illustrate reading weblogs, I included a screenshot of my Outlook newsgator subscription list. I didn't include a screenshot of creating a post, but I did include a screenshot of my dotnetweblogs home page for him to observe the how I was blogging with a dotnet subject-specific focus.
There are potential downsides of corporate blogging, of course, which I touched on but didn't have to emphasize. I also made it clear that I wrote the paper on my own time, since he wasn't paying me for doing position papers on weblogging. I will post any company blogging developments here. For now, I wanted to provide the paper's bibliography. I want to give a personal plug to "We Blog. Chapter 8" listed below. I need to buy the book! Everyone should at least read the online chapter listed here.
If indeed "Blogging is the next big thing" as I keep reading, then we as IT Professionals who enjoy its benefits today should present the technology to the decision makers in our organizations for them to determine its benefits on their own. If it does explode as we anticipate, it also confirms that we IT guys are on top of technological trends as we should be.
Newsgator RSS News Aggregator for reading blogs in Outlook
Danbricklin.com article: Small Business Blogging. Good specific extranet examples.
NY Times article on Business Blogging posted 3 days ago: The Corporate Blog is Catching on. An “okay” general overview. Touches on Corporate Policy and legal considerations
We Blog. Chapter 8: Using Blogs in Business. A thorough look at the uses of blogs in business.
DotNetWeblogs Home Page. Community website for developers which hosts my weblog.
Dave Burke’s blog. What I’m blogging about in regards to .NET and development issues.
Robert Scoble’s Weblog. Extremely popular website from a software evangelist at Microsoft. (One of many Microsoft employees who blog.)
Ray Ozzie’s Weblog policy for Groove: Weblog guidelines for Groove employees.
I have the good fortune to be working with Microsoft Sharepoint and extracting Web Storage System folder and document information to what I call an Intelligent Middle XML Layer to free us from the digital dashboard (not big fans), combine our Sharepoint data with SQL and Exchange, improve searching, tc. But that's another post. Amidst the cool aspects of working on this app, I encountered a stupid parsing issue that frustrated me for more than a few minutes. While this post is in the D.O.T.D. category, it was more like Stupidity Of The Day (S.O.T.D.) activity.
I needed to extract the project number from folder urls, in this example "20036969." I pass the year, assign the URL to s, and parse.
The Substring needs a starting position and length. Pretty simple. Calculating the length was my problem. The " - " string always follows the project number, so I marked its position and substracted the position of what I thought was the "start" of the number: s.IndexOf("/" + year + "/") + 6. Wrong. This subtraction yielded 16. I needed to reduce the length by the "/" + year + "/" string, so it was - 6. (I welcome a smarter calc at this length--maybe a single overloaded IndexOf()?)
I should apologize for the boring subject matter of this post: Substrings. But hey, at least I didn't write about a garbage disposal incident. A couple of morals: 1) the (parens) mark the spot. It's easy to get confused with the overloads of the IndexOf() method. Calculations happen outside of the parens or hard to decipher runtime errors will waste CPU and brain cycles, 2) starting point, length. Starting point, length, and 3) it's always the most mundane issues that kick your butt.
From Mike Gunderloy's Daily Grind 108
Hypothesis: The amount of effort a new blogger puts into updating their blog after their first two entries is inversely proportional to the number of "wow, look who's blogging now!" posts that their original appearance triggers.
Very astute observation with which I would agree.
I think it is so cool how web control objects are so well integrated in the page object level. I am speaking particularly about validation controls. Today I encountered a RequiredField Validator in a web control not being triggered when I clicked the button in the .aspx. I was sure everything was correct in the .ascx and the .aspx. It turned out that in the web control I had disabled the validator (reqTxtWhatever.Enabled = false;) for a given condition and failed to re-enable it. This stuff works great as long as I don't do anything stupid.
Related to my UI<-->biz<-->data kick, I'm seeing a new simplicity in my code, primarily in the UI layer. I should find a better term, but I will use the term "abstraction" to describe the following statement:
oUBizObj.DoSomething("thisstring", MethodReturnsAString(string) , id, enum.datatype))
It dynamically executes a SQL query which updates a field (thisstring) with a value (MethodReturnsAString(string)) for a given record (id), with the sql statement details built from the enum.datatype value.
My point is that with a more sophisticated data layer backend, statements used frequently like this one which perform data processes can be entered easily and provide no indication whatsoever to what is actually happening in the backend. To me, that is abstract. And quite cool.
I've been coding and talking recently about strict logical layers with tight UI code that always passes through the business layer on its way to the data layer. I'm doing this (as I mention in an earlier post) in preparation of moving from webforms to winforms. Along these lines I have been employing web controls much more and see an interesting pattern emerging.
I use public data classes in the business layer which serve to pass data from the UI to the data layer, or vica versa. These are readily available to all pages, controls and components. This is cool but hardly new or interesting. But while coding with this "middle pass-through" mentality I have discovered the efficiency of enums; that is, enums which are also declared as public and at the namespace level. It is very simple to set an easily-identifiable action switch across the layers using enums declared as public in the business class.
I have had the extreme good fortune to be able to rewrite a few asp.net wizards from scratch that I first wrote a year-and-a-half ago. Every developer should have this opportunity for two reasons: 1) to demonstrate how far he or she has come since writing the original app (feels pretty good), and 2) to perform restitution to those poor users who have had to use the original.
We as developers seem to rarely get an opportunity to completely rewrite an old app, so it gave me an opportunity to think about the differences.
1) The original was written in VB.NET. I've since moved to C#.
2) Layers. The new wizard design has a strict UI, business, and data layer design.
3) Web Controls. I used web controls from the beginning but the more I use them the more I appreciate how clean they make the .ASPX and code-behind pages, as well. I am becoming a big fan of Web Controls.
I've been writing data-driven web apps since 1995, and it didn't take long to realize that the web UI sucks. As I heard Tom Eberhard say in a recent conference session on the topic of chosing winforms or webforms: "The Web was never designed or intended to be used for normal data driven application UIs." If you think about the early efforts of Tim Berners-Lee at CERN, Andreeson with Mosaic at NCSA, and others, the web was never about data-driven applications. But that's not my point of contention with web apps.
It's the UI, dweedlehead. Users have long had to suffer with marginally functional web widgets, like the drop down list, for instance. And forget about a simple combo box! Yeah, yeah, there are smart guys out there with incredibly cool hacks like Andy Smith whose work is excellent and who I really respect, but you're still putting a silk purse on a sow's ear with this sort of approach.
Which is, of course, where .NET Winforms comes into play. Okay, I'm done preaching to the choir. This post is to cover my approach in moving existing web applications to a winforms future.
Again, thanks to Tom , I "got it," and have been building truly logical layers, keeping the UI layer tightly tied to the UI (currently web forms and web controls), building a business class layer for ALL non-UI logic, and a fully separate database layer. In other words, I am building every web app with the idea of replacing it with a winforms front end, so I am constantly thinking how to build it for today's web requirements and yet easily upgrade it to a winforms app.
A few self-imposed design enforcements are:
1) The business layer holds ALL non-UI logic. All of it.
2) Public class objects reside in the business layer to which data can be easily passed from either a web UI or a future winforms UI.
3) The UI layer never talks to the data layer directly without first passing through the business layer. Never. If I need to populate a dropdown, for example, I have a public DataTable GetWhatever() business layer method which simply (for current web-based apps) returns the public DataTable GetWhatever() datatable from the data layer method of the same name. It seems redundant, but this way, the business layer can be easily uncoupled from the data layer if, in a future winforms extranet scenario to replace the current web-based app, I need to call a Web Service-based data layer.
Another result of this approach is how much cleaner and more, uh, logical the code is in each of the various layers.
Here is a document in Word format containing rather detailed notes of 16 conference sessions I attended last month while at DevTeach, Montreal. Session topics cover several Winforms topics, inheritance, XML, and the Compact Framework, with such speakers as Carl Franklin, Tom Eberhard, Kevin Mcneish, Ted Neward, and Julia Lerman. Enjoy.
I took these notes with my Dell Axim and portable keyboard. Here is the pic of Axim and keyboard. Very sweet setup for session note taking! Since I carry my PocketPC with me most of the time, during idle time I can easily re-read the original which still resides on my PDA to remember the cool stuff I wanted to investigate.
More Posts Next page »