Wednesday, January 12, 2005
GMail
I have four GMail invites if anyone is interested. Offer some constructive comments to one of my technical posts and an invite is yours! [First come, first serve but the invites will only be given if a relevant, thought provoking comment is posted]
Saturday, January 08, 2005
A Matter of Great Importance
It has been a while since my last post. Work and the holidays have kept me pretty busy. During the past few weeks, I have had some time do so some of the reading that I have been meaning to do. Based on the content of the various books and journals I have been reading, it seems as though there is a great, ongoing debate as to which part of an application is more important: the user interface (UI) or the back-end code (for the purposes of this entry, I am including any data storage mechanisms and logic code including databases and stored procedures).
To me, this debate seems pointless. The answer to the question of "which is more important?" is really quite simple...both parts are equally important!
The equality of importance is apparent when one examines the true purpose of a program. The true purpose of a program is to make some task easier and more efficient for someone. It is extremely important to never lose sight of this purpose since doing so will negatively impact the quality of the end product.
Both parts of a program directly impact the overall user experience. Obviously, the UI is what the end user sees and interacts with. If the UI is cumbersome and/or difficult to learn, the task has not been simplified and may in fact have actually become more difficult. User interfaces must be intuitive.
On the other side of the coin, if the back-end performs poorly (including stability issues), the user becomes upset because although the task may have been simplified, it may not be more efficient. Even the perception of poorly written code will ultimately result in lower user satisfaction. Therefore, it is important to minimize the level of poorly written code in order to minimize areas of poor performance and the perception of poor performance.
The most elegant user interface ever designed cannot save an application with a poorly written back-end. The most efficient logic code ever written will not be used or appreciated if the user cannot figure out how to exploit it because of a cumbersome UI.
It is for these [brief] reasons that I believe that equal time should be spent on the design and implementation of both the user interface and back-end portions of any program. Only when all components have been well designed and developed will user satisfaction reach its maximum potential.
To me, this debate seems pointless. The answer to the question of "which is more important?" is really quite simple...both parts are equally important!
The equality of importance is apparent when one examines the true purpose of a program. The true purpose of a program is to make some task easier and more efficient for someone. It is extremely important to never lose sight of this purpose since doing so will negatively impact the quality of the end product.
Both parts of a program directly impact the overall user experience. Obviously, the UI is what the end user sees and interacts with. If the UI is cumbersome and/or difficult to learn, the task has not been simplified and may in fact have actually become more difficult. User interfaces must be intuitive.
On the other side of the coin, if the back-end performs poorly (including stability issues), the user becomes upset because although the task may have been simplified, it may not be more efficient. Even the perception of poorly written code will ultimately result in lower user satisfaction. Therefore, it is important to minimize the level of poorly written code in order to minimize areas of poor performance and the perception of poor performance.
The most elegant user interface ever designed cannot save an application with a poorly written back-end. The most efficient logic code ever written will not be used or appreciated if the user cannot figure out how to exploit it because of a cumbersome UI.
It is for these [brief] reasons that I believe that equal time should be spent on the design and implementation of both the user interface and back-end portions of any program. Only when all components have been well designed and developed will user satisfaction reach its maximum potential.
Sunday, December 19, 2004
Caution: Education Ahead!
Ok, so I admit that I'm a little behind the curve on some of the technology that is available right now but all that is about to change. For my birthday, my wife presented me with a new Seagate 80GB hard drive which I am proud to say, installed without any problem. As I was installing the drive, I even decided that with the CD burner and a 256MB flash drive, I no longer needed the floppy drive installed so I'm finally running without a 3.5" drive on all of my computers.
The reason I asked my wife for a new hard drive is so I could set up my system for dual boot with a developer license of Windows Server 2003 Enterprise Edition and load other software such as SQL Server 2005 Beta 1 and Visual Studio 2005 Beta 2 so I could get myself up to speed on the upcoming technology. I don't have everything installed yet since I still have to download the MSDN portion of Visual Studio but what I have installed so far impresses me beyond my wildest dreams.
Even though I have been reading some about SQL Server 2005 tonight was my first exposure to it and therefore, it was my experience with SQL Server Enterprise Studio. I must say that so far I like what MS has done. The whole Visual Studio-like interface seems to be extremely intuitive and easy to use from what I have looked at. I know that I have barely scratched the surface of the new tools and I am also left wondering how many DBAs will like the extreme change.
In all honesty, tonight was also my first exposure to Windows 2003 Server and I am also impressed with it. I know that the product has been available for some time but I have not had access to any resource to dig in and fiddle around. I am looking forward to playing around with IIS6 and many of the other enhancements over Windows 2000 though I'm really primarily interested in SQL Server 2005.
As I was opening the box in preparation to install the new drive, I asked my wife if she realized that the present meant I was going to disappear into my home office more than I usually do since she was opening the door for me to install a shload of new "toys," She said she did but we'll see! As I learn more about SQL Server 2005 and Visual Studio 2005 I'll be sure to post it here.
The reason I asked my wife for a new hard drive is so I could set up my system for dual boot with a developer license of Windows Server 2003 Enterprise Edition and load other software such as SQL Server 2005 Beta 1 and Visual Studio 2005 Beta 2 so I could get myself up to speed on the upcoming technology. I don't have everything installed yet since I still have to download the MSDN portion of Visual Studio but what I have installed so far impresses me beyond my wildest dreams.
Even though I have been reading some about SQL Server 2005 tonight was my first exposure to it and therefore, it was my experience with SQL Server Enterprise Studio. I must say that so far I like what MS has done. The whole Visual Studio-like interface seems to be extremely intuitive and easy to use from what I have looked at. I know that I have barely scratched the surface of the new tools and I am also left wondering how many DBAs will like the extreme change.
In all honesty, tonight was also my first exposure to Windows 2003 Server and I am also impressed with it. I know that the product has been available for some time but I have not had access to any resource to dig in and fiddle around. I am looking forward to playing around with IIS6 and many of the other enhancements over Windows 2000 though I'm really primarily interested in SQL Server 2005.
As I was opening the box in preparation to install the new drive, I asked my wife if she realized that the present meant I was going to disappear into my home office more than I usually do since she was opening the door for me to install a shload of new "toys," She said she did but we'll see! As I learn more about SQL Server 2005 and Visual Studio 2005 I'll be sure to post it here.
Saturday, December 11, 2004
Recent Events
It has been a few days since my last post and a lot has been going on. Over the past week I have:
The OO session focused on the concepts as they related to VB.NET and were presented in a simplistic manner. In all honesty, I found it a little hard to believe that in a theatre full of .NET developers, there were plenty of people that were unfamiliar with the pillars of OO development. It also seemed as though much of the emphasis was placed on abstraction and encapsulation as opposed to inheritance and polymorphism, the main principles on which the .NET framework is based!
The MapPoint Web Services session seemed kind of pointless and seemed like even more of a sales pitch than anything else. Are there applications for the Web Services? Sure, but the many applications that need some mapping functinality will be better served by linking to MapQuest. The bottom line from this session is that MapPoint is expensive, has inflexible licensing, and, although powerful, is probably overkill for many applications.
As I mentioned earlier, the best session (and actually the reason I attended this event) was the session regarding ASP.NET application optimization. At first, I was disappointed with this session since much of the first 45 minutes focused on the tools and how to use them. I am a programmer and, naturally, a tinkerer. I want to figure out the tools on my own (and trust me, they're not that complicated to use), not have every feature demonstrated. Some nice tips such as running the tools on a separate box than where the site is hosted were covered but I was looking for tips on how to actually improve performance.
Fortunately some tips were eventually discussed. Unfortunately most of them were ones that could be found in any ASP.NET book. Optimizations discussed included:
A positive note about this session is that the presenter (Jacob Cynamon) continually emphasized the importance of designing performance into the application from the start. Poor performance should not be acceptable for any application. Applications should be tweaked to ensure the most efficient execution path is executed rather than a method that is simply easier to maintain. I am not arguing that maintainabilityis not important but I am arguing that usability is and performance directly impacts usability. Making users wait on your application because of poorly written, inefficient code is unacceptable. Of course, the amount of acceptible wait time varies by task but making users wait longer than necessary is a sign of low quality.
Moving on from my side rant, I did not stay for the final session. I originally intended on sticking around but decided that I will look into ASP.NET 2.0 on my test workstation when I get around to setting it up rather than sit through a presentation on beta software. I'm sure that many of the new features in ASP.NET 2.0 will make my life easier but for now, I am not interested. When the next version is closer to release, I'll look into this in more detail.
That really seems to wrap it up for the overview of the MSDN Event. Until next time, happy coding!
- Found a host and launched a web site for Springfield Publications
- Attended an MSDN event in Greenwood, Indiana
- Attended the year-end/holiday event for my organization
- Started my holiday shopping
The OO session focused on the concepts as they related to VB.NET and were presented in a simplistic manner. In all honesty, I found it a little hard to believe that in a theatre full of .NET developers, there were plenty of people that were unfamiliar with the pillars of OO development. It also seemed as though much of the emphasis was placed on abstraction and encapsulation as opposed to inheritance and polymorphism, the main principles on which the .NET framework is based!
The MapPoint Web Services session seemed kind of pointless and seemed like even more of a sales pitch than anything else. Are there applications for the Web Services? Sure, but the many applications that need some mapping functinality will be better served by linking to MapQuest. The bottom line from this session is that MapPoint is expensive, has inflexible licensing, and, although powerful, is probably overkill for many applications.
As I mentioned earlier, the best session (and actually the reason I attended this event) was the session regarding ASP.NET application optimization. At first, I was disappointed with this session since much of the first 45 minutes focused on the tools and how to use them. I am a programmer and, naturally, a tinkerer. I want to figure out the tools on my own (and trust me, they're not that complicated to use), not have every feature demonstrated. Some nice tips such as running the tools on a separate box than where the site is hosted were covered but I was looking for tips on how to actually improve performance.
Fortunately some tips were eventually discussed. Unfortunately most of them were ones that could be found in any ASP.NET book. Optimizations discussed included:
- Using caching
- Using connection pooling
- Open late/close early technique for database connections
A positive note about this session is that the presenter (Jacob Cynamon) continually emphasized the importance of designing performance into the application from the start. Poor performance should not be acceptable for any application. Applications should be tweaked to ensure the most efficient execution path is executed rather than a method that is simply easier to maintain. I am not arguing that maintainabilityis not important but I am arguing that usability is and performance directly impacts usability. Making users wait on your application because of poorly written, inefficient code is unacceptable. Of course, the amount of acceptible wait time varies by task but making users wait longer than necessary is a sign of low quality.
Moving on from my side rant, I did not stay for the final session. I originally intended on sticking around but decided that I will look into ASP.NET 2.0 on my test workstation when I get around to setting it up rather than sit through a presentation on beta software. I'm sure that many of the new features in ASP.NET 2.0 will make my life easier but for now, I am not interested. When the next version is closer to release, I'll look into this in more detail.
That really seems to wrap it up for the overview of the MSDN Event. Until next time, happy coding!
Sunday, December 05, 2004
Any Command Line Lovers Out There?
To be honest, much of the buzz about Longhorn hasn't really gotten me very excited. All that I've been really interested in is WinFS but I haven't spent much time looking into it yet. Tonight I ran across something called "Monad" which managed to get my attention.
Announced at the Professional Developer's Conference, Monad is a replacement for cmd.exe. Personally, I love using the command line. I've always found that most administrative tasks are much easier to perform using a command line interface than to dig through layer upon layer of windows and dialog boxes just to click one check box. Sure, some things are clumsy in the command line but at least its fast, there's no question about what is actually happening, and most important, there's NO DIGGING! I even extend this to database administration where I prefer to use Query Analyzer to Enterprise Manager for most SQL Server administrative tasks.
You can imagine my dismay when I read that my favorite tool in Windows administration was being replaced. "What could they possibly do to it?" I wondered.
Long story short, Microsoft has finally decided to catch up with the rest of the operating system world and switch to a pipeline based model. The nicest thing about Monad is that rather than being an ASCII based pipeline, its a .NET object based pipeline. What does all this mean? It means that administrative tasks are going to get a whole lot easier!
Perhaps one of the nicest examples I've seen regarding how Monad simplifies administrative tasks comes from an article on TechWorld. In the example, the task of enumerating processes to determine how much memory is being used by each process in Windows 2003 (using some third party tools) is compared to the same task on Monad. Basically, rather than writing a custom script in Python, a new "get-command" command has been added which returns a collection of System.Diagnostics.Process objects which can be piped to Excel, an HTML file, or a .NET Grid control. The results can even be piped to further commands.
Maybe Longhorn isn't going to be so bad afterall!
For more information about Monad, Google "Monad"
Announced at the Professional Developer's Conference, Monad is a replacement for cmd.exe. Personally, I love using the command line. I've always found that most administrative tasks are much easier to perform using a command line interface than to dig through layer upon layer of windows and dialog boxes just to click one check box. Sure, some things are clumsy in the command line but at least its fast, there's no question about what is actually happening, and most important, there's NO DIGGING! I even extend this to database administration where I prefer to use Query Analyzer to Enterprise Manager for most SQL Server administrative tasks.
You can imagine my dismay when I read that my favorite tool in Windows administration was being replaced. "What could they possibly do to it?" I wondered.
Long story short, Microsoft has finally decided to catch up with the rest of the operating system world and switch to a pipeline based model. The nicest thing about Monad is that rather than being an ASCII based pipeline, its a .NET object based pipeline. What does all this mean? It means that administrative tasks are going to get a whole lot easier!
Perhaps one of the nicest examples I've seen regarding how Monad simplifies administrative tasks comes from an article on TechWorld. In the example, the task of enumerating processes to determine how much memory is being used by each process in Windows 2003 (using some third party tools) is compared to the same task on Monad. Basically, rather than writing a custom script in Python, a new "get-command" command has been added which returns a collection of System.Diagnostics.Process objects which can be piped to Excel, an HTML file, or a .NET Grid control. The results can even be piped to further commands.
Maybe Longhorn isn't going to be so bad afterall!
For more information about Monad, Google "Monad"
Subscribe to:
Posts (Atom)
