Expert Answer Center > Experts On Demand
EMAIL THIS
Experts on Demand
  EXPERTS ON DEMAND HOME     POSE A QUESTION     VIEW ANSWERS     BROWSE BY TOPIC        RSS FEEDS  
FEATURED TOPIC: VS.NET/VB.NET
VIEW FEATURED TOPIC PAGE
VB.NET/VS.NET
Blog Host:
Samuel Matzen - Founder/developer
READ ENTIRE BIO
Fun development projects -- not an oxymoron
22 APR 2005 10:14 EDT (14:14, GMT)
A couple of years ago I was involved in a very interesting project for the largest developer of wholesale auto parts software in Germany.

The first project I worked on for this client was the creation of a shopping cart application deployed on SCO Unix 5.0.5 integrated through shared memory with the legacy Niakwa Programming Language (NPL) on the Apache server and implemented with CGI scripts and a little C. I got involved with this application because of my association with Niakwa and because I had just spent a couple of years developing an integrated development environment for NPL using VB6.

The second project also ran on top of the Apache server and integrated with NPL but was a Web service that integrated with a Web-based auto parts catalog.

Another project I wrote for this client was an automotive repair shop application written in VB6, deployed with the Microsoft Data Engine (MSDE), with full use of the Infragistics suite of presentation-layer components. One interesting twist to this application was the integration to the legacy NPL database used a managed telnet session to query inventory and place orders into the server's shopping cart system.

I speak very little German and the lead programmer for my client speaks little English. However, we were able to communicate very well with the keyboard and code. We couldn't understand each other's speech, but we would hand the keyboard back and forth and program. The only real problem is the German keyboard has the Z and Y keys reversed. It took a little getting used to.

In retrospect, I would have to say these projects were probably the most fun I have ever had as a developer. Getting to use my unique understanding of NPL, SCO Open Server, VB6, HTML and C made it fun.
Posted by Samuel Matzen How fun jobs can get less fun
21 APR 2005 21:08 EDT (01:08, GMT)
As a contract developer, I don't often get to do many fun jobs and usually have to take the jobs I can get.

Now that I have a Class A motor coach, my wife and I can go where the fun jobs are and get paid a whole lot more money. High-end development jobs are hard to find and usually there is little to no relocation assistance. I can be anywhere in the U.S. in four to five days and stay as long as I need to. Except the coach doesn't like too much cold, but neither do I. So we need to be in the South in the winter.

Last August I took a really fun engagement in Tampa, Fla. as a senior software architect developing a full ERP for the automobile dealership market on top of ASP.NET. This was a fun project because I was able to work with some of the best programmers I ever have worked with and had a really good DBA.

It was a really fun project, but it had a couple of critical flaws:

  1. The project was not fully funded when it started, so when the project was about 70% complete, the company ran out of money.

  2. The project started changing the first week and encountered major changes almost weekly. This wasn't really much of a problem because the bulk of the programming we were working on was not affected by the changes, but our compensation was tied to critical milestones that were obtainable when the project started, but after the first four weeks were no longer possible to meet. And the compensation plan was not modified. So, when the milestones were not met, the staff moral suffered significantly.
All-in-all it was a really fun project, and I made many new friends.
Posted by Samuel Matzen My dev environment
20 APR 2005 15:56 EDT (19:56, GMT)
Many younger developers ask me about my development environment because I seem to be able to produce robust applications quickly. First, I have a fairly quick development machine used only for development. My e-mail and other personal applications are on my HP NX9500 laptop. Then I use "best-of-breed" third party components.

Hardware

  • Intel 3.0 GHZ Pentium with 3GB RAM (I actually have 4GB RAM but XP will only use 3)
  • Four 100GB hard drives in a RAID10 (mirrored and stripped) configuration
  • Matrox Perihelia board with three Sony G520 21" monitors.
Software
  • Windows XP Pro with latest service pack and hotfixes
  • Microsoft MSDN Universal Subscription
  • Infragistics NetAdvantage Suite (Presentation Layer)
  • Active Reports (Data Dynamics) for integrated reporting
  • InstallShield for installation packages
  • RoboHTML for documentation and external help files
Techniques
  • I typically use SQL Server as the database and have deployed workgroup applications with MSDE and larger applications with SQL Server on a powerful server.

  • The Infragistics presentation layer components provide rapid development of both ASP.NET and Windows forms applications. These are high-performance components and require a little time to get used to. Infragistics news groups and support are excellent resources to help you over the bumps.

  • Most of my applications have required built-in reports and Active Reports is one of the best reporting tools I have ever used. I have even used it to present data views on Windows forms.

  • InstallShield is one of the best deployment tools, but again it will take a little time to gain experience with it.

  • Robo Help is the best documentation tool I have ever used. I generally use the RoboHTML version, which allows you to enter your documentation once and publish to many different output formats, including Word documents.

  • When starting a project using technologies or techniques I have not used before, I have found that developing prototypes to use every technology, feature and technique you will need before starting to develop the application will flush out those things you "assume" will work but really don't. I can't count the number of times I have worked on a project for weeks only to find out that one of the more sophisticated features of a component doesn't work and it will take six months to get a fix. Or (and you probably had this happen) the product is being developed on a more powerful machine and will not deploy on older operating system versions like Windows 98. Remember running out of resources on Windows 98?

  • And I use Microsoft Project for project management. It probably isn't the best tool available, but since it is a part of MSDN Universal, so the price is right. ALWAYS manage your project. If you do not know where you are going, you won't ever get there.

Posted by Samuel Matzen Take care of yourself
18 APR 2005 23:39 EDT (03:39, GMT)
Wow, it was a really nice weekend here in central Florida. A trip to Disney on Saturday and a visit to Clearwater Beach on Sunday highlighted two really nice days off.

Two days off in this business? Sacrilege!

As you might have picked up from previous blog entries, I have been programming since 1967 and am 56 years old. Most of my life I've worked 6- and 7-day weeks. Much of this time away from home and family doing custom development in languages I don't even remember the names of.

The long hard days, eating high calorie/fat fast food, not to mention other vices too numerous to mention. Was it worth it? Would I do it again knowing what I know now?

No, I wouldn't. The lifestyle ruined my health. I am on my way back to good health again, but it will be a long hard road.

There are two kinds of developers: those who have ruined their health for their profession and those who are probably going to. So, for what it is worth:

  • Take a job that keeps your hours down under 55 hours per week.

  • Don't let your supervisors put all of the stress on you. You need to perform, but someone else's bad planning shouldn't become an emergency for you.

  • Eat right. Contact a dietitian and find out what you should eat for your health profile. And stick with it.

  • Get an annual checkup with complete blood work from a doctor who will be straight with you about your health. You might be surprised what a good doctor can tell from your blood work numbers.
Yes, I am trying to get you to take a look at your health. Trust me, when you get older you may regret the damage you do to your body when you are young. That is, if you get the opportunity to get older.
Posted by Samuel Matzen ASP.NET, session state and view state
15 APR 2005 20:06 EDT (00:06, GMT)
The ASP.NET environment is stateless. This means that while the Web page is on the browser, the code behind is completely destroyed. So when the user clicks on a control causing a postback, the Web server reloads your application, but all of the objects you used to create the original page are now gone. Object instances and variables (also objects, but that is another subject) have been destroyed.

ASP.NET supports a number of different ways to deal with the stateless environment; the most popular are session state and view state.

Session State
Session state is a collection of key/object pairs persisted between post backs. Use of session state as implemented in ASP.NET has a couple of issues you need to be aware of:

  • Since it is implemented with key/object pairs, each object requires a key. This works fine for small projects, but when a project starts to become more robust you will find it becomes difficult to keep track of which key values have been used. In a team environment this can become a serious issue.

  • These problems and others can be solved by creating a Session State class and exposing public fields or properties. This provides strong names and strong types for each of the session state fields. This session state class can save/load the values anywhere convenient. In my last robust ASP.NET project we persisted the values in SQL Server.
View State
View State is how ASP.NET preserves values for presentation layer controls between postbacks.

This is implemented by the controls responding to events to save/load properties and ASP.NET encapsulates these properties in some kind of object and encrypts the data. This encrypted text is then included as a hidden field on the Web page. When the user causes a postback, ASP.NET decrypts the view state in the hidden field value, throws an event to each control on the page and returns the requested properties.

This all works really well until your application needs to run on slow connections or your view state become huge. For some applications where grids are used, I have seen view states of over 500 KB.

This issue can be overcome by intercepting the decoding and encoding events and placing the view state in a data store on the server and only send the session ID or GUID in the pages view state. In my last robust ASP.NET project we persisted the view state in SQL Server.
Posted by Samuel Matzen Code regions
14 APR 2005 17:08 EDT (21:08, GMT)
For the casual programmer, source code structure and standardized code documentation are not generally a high priority. For the serious developer, source code structure and standardized code documentation is almost as important as the code itself.

I routinely work with code I wrote 25 years ago; I have no problem understanding and updating the applications because the code was consistently documented. In those days we didn't have graphical editors -- we used line editors, so our languages were line-number based. These applications were originally developed in Wang Basic and later converted to the Niakwa Programming Language (NPL). The following is a snippit from a program I wrote circa 1980.

4010 REM 
4020 REM PROGRAM ENTRY POINT
4030 REM 
4050     DIM C$(18)3: REM DEVICE TABLE NAMES
4060     DIM D0$(256)3,D1$(256)32,D0$2
4061     DIM X0$(51)3,X1$(51)32
4070     DIM Z0$64
4080     DIM N11$(40)3,N12$(40)4,N13$(40)12,N14(40),N11$3,N11,N12$40
4090     DIM N1$2: REM SEARCH RESULTS
4100 REM *********************************************************************
4102 REM                    LOAD THE SCREEN DEFINITION
4104 REM *********************************************************************
In those days we assigned line number ranges for the various code regions. For instance line numbers 2000-2500 were for database descriptions and line numbers 4000 to 4999 were for variable declarations.

VS.NET now supports formally named regions that can be collapsed and expanded as needed. This is probably my favorite feature of VS.NET over the previous VB6 development environment. For robust applications, standards are needed to make optimal use of named regions along with naming conventions. These standards not only provide the individual programmer with consistency from one program to another, but provide the standards needed for team development.

If you don't already have standardized region names and sequence (the order of the regions in the module is almost as important as the name) and naming standards, the following will help get you started.

Coding Conventions

Naming regions
Use the following code region names in the following order whenever possible.

Region names should have a space prior to the first character and a space after the last character to increase readability. Also, when all regions are collapsed you should have one blank line between each region.

  • Event Declarations
    Declare the event arguments classes and the events in this region.

  • Private Class Instance Declarations
    Declare any external classes you are going to use. Most pages contain something like:

      Private _SS As xxx.Lib.SessionState
      Private _WebPage As New xxx.Lib.WebPage
      Private _MenuData As New xxx.Lib.MenuData
      Private _Appearance As New xxx.Lib.Appearance
    
  • Private Declarations
    Declare your private variables here. Remember to prefix your private class scope variables with an underscore ("_").

  • Private Property Declarations
    Declare your private property declarations here. These should be prefixed with an underscore.

  • Public Properties
    Place your public property get/set code here.

  • Public Methods
    Place your public methods in this region.

  • Private Methods
    Place your private methods in this region.

  • Page Events
    Place any page events in this region.

  • Individual Control's Events
    Add a new region for each control or group of controls below the Page Events region. For instance if you have a WebGrid on your page you will want a region named "WebGrid Events ."
General Naming Conventions
Use "Pascal Case" or "humpback." Try to avoid abbreviations.

Naming ASPX Page
Always place the class name at the beginning of the ASPX page name. For instance, the Cash Receipts Edit page would be named CashReceiptsEdit.aspx.

Naming Controls
When naming controls and variables, try to use standard prefixes such as dt for DataTable.

Method Parameter Naming
Use a "v" prefix for ByVal and "r" prefix for ByRef. You don't need to use Hungarian-style notation for parameter naming because intellisense provides you with the type of the parameter whenever you need it.

Naming Local Variables
Prefix with Hungarian-style notation and use camel case as a general rule (e.g., strLine1, intNumber).

Constant Naming
Use uppercase with words separated with underscores (e.g., MAX_HEIGHT, MIN_WIDTH).

Option Strict
Option Strict is not an option. Set Visual Studio and the projects to always have Option Strict on.

Imports
Use Imports sparingly, if at all. It is preferable to see fully qualified names in the code, and you won't have namespace clashes.
Posted by Samuel Matzen VS.NET multiproject assembly references
13 APR 2005 06:07 EDT (10:07, GMT)
Setting the stage
You have been developing standalone .NET applications, referencing parts of the .NET namespace and referencing third-party assemblies. You already know many of the assemblies are stored in the GAC (Global Assembly Cache) and are automatically included in the .NET References dialog. You might have even written your own assembly as a project in a separate solution and added your own custom reference to the assembly.

Now you are ready to develop multiple reusable assemblies and an application in the same solution.

In an enterprise outward-facing ASP.NET application I architected last year, we had six programmers and a DBA (Data Base Administrator) working on the application. The application was persisted in a Source Safe server. There were about fifteen different application modules such as Persons, Addresses and Products. All of these modules used shared data and logic solutions (assemblies), and many of the other modules were shared across multiple solutions. To provide maximum granularity, there were about 15 data layer solutions (code-generated), 15 logic layer solutions and 20 application projects and solutions.

When a programmer was assigned work on an application they would get the latest version on the data layer and business logic layer solutions (each in a separate directory) and check out the application solution.

Each application solution consisted of one application project. All referenced data and logic projects were included in the solution. Many of the application solutions contained 12 or more projects.

The important part
In a solution where there is a top-level project and multiple referenced projects, be sure you don't reference the assemblies directly or VS.NET will get very upset and exhibit very unusual behavior. When you open the References dialog to add a reference to your solution, you will see a "Projects" tab. Click on this tab and select the projects you would like to reference.

When designing your applications, remember you can't have circular references.
Posted by Samuel Matzen News groups and expert answers
12 APR 2005 06:26 EDT (10:26, GMT)
When posting questions on News Groups or Ask the Expert sections of TechTarget's search sites, you need to provide brief but complete information. Many of the questions I have received lately have been too brief and miss-targeted. Well-formed questions should include:

  • Title
  • Technologies
  • Question
  • Sample code
  • Screen caps
When sending questions to experts, the title and technologies sections are extremely important so the question can be easily routed to the expert with the appropriate experience.

When posting questions on news groups, the title is extremely important to catch the eye of someone who wants to take a shot at providing the answer. The technologies should be outlined early in the question so the expert can quickly determine scope and not spend a lot of time on questions outside his knowledge and experience.

Many questions will require the expert to create a sample project to see what is really happening. Make sure your question provides enough detail for the creation of a sample project with sample code and screen caps.

Many of us spend time answering questions on news groups to learn more about the topic. I have found that when developing applications I generally use a small subset of the capabilities of the environment and controls. The news groups allow me to participate in the development of hundreds of other applications and expand my scope of experience with the environment and controls much further than would be possible otherwise.

Also remember most experts are unpaid for their efforts. They do it for experience and sometimes recognition, such as the MVP programs and the privilege of being labeled an expert.

And if you are really serious about being a professional developer, spend some time answering questions on the news groups. You might just find it is addictive.
Posted by Samuel Matzen VS.NET/VB.NET -- Where we are today
11 APR 2005 05:47 EDT (09:47, GMT)
VS.NET and VB.NET as topics are huge, and I don't pretend to have used every aspect of either. I have created projects using these tools for both Windows Forms and ASP.NET and have architected projects developed by teams. All things considered, VS.NET and VB.NET provide the developer with a significant advancement over VB6, even though the size and complexity of the .NET namespace and complete language restructuring have been troublesome for those trying to upgrade applications.

In general I have found that education and experience don't provide us with all the knowledge we need to select and deploy technology, but they do provide us with a repository of methodologies and techniques that do and do not work. What we think we know today must be continually tempered with new products and new releases.

Ten years ago I would not have loaded a beta development system on my machine, but today I have Whidbey (VS.NET 2005 in beta) loaded along with the latest beta versions of my preferred presentation layer suite. Working with beta products is not for everyone, but if your product is slated for delivery a couple of months after the scheduled release of the products, it is an ideal way to get a jump on the new releases and provides the developer with a direct communications pipeline to the tools developers use.

Even with all of its problems, I have found VS.NET to be an effective development environment, and I expect the release version of VS.2005 will have just as many problems and we will cuss it when it isn't as intuitive as we think it should be. I just hope Microsoft actually uses the update features in VS.2005 so the identified issues can be corrected in a timely manner, rather than having to wait years for a new release.

That all being said, I will start talking about some of the advanced features of VS.NET and VB.NET I have found to be useful.
Posted by Samuel Matzen

MOST RECENT BLOG TOPIC ENTRIES
NOV 2009
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
PREVIOUS ENTRIES OTHER BLOG TOPICS
HomeExperts on DemandIT Expert Webcast SeriesExpert KnowledgebaseSite Index
TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of technology-specific websites, events and online magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Site Map




All Rights Reserved, Copyright 2009, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts