An Ozzie in Boston

Software Development – Releasing with FinalBuilder

 

Photo courtesy of Wikipedia, bad joke and art courtesy of me. 

 

So at the Company I work for, I’m basically a one man band when it comes to programming. This means I do everything. I go through the whole software development life cycle. And I have to do it quickly. But there’s one part of the cycle that I have to do quickly, and it get right, the first time. Can you guess what it is?

 

It is the RELEASE.

 

The release process at my company is this:

1. I finish testing the software on my computer – this is called the debug build.
2. I transfer this software to another computer and receive the output through my computer – this is called the test build.
3. My supervisor transfers the software to the release computer on a different part of the computer to the release build, and receives the output through the release computer, on a different part of the computer to the release build – this is called the staging build.
4. My supervisor transfers the software to the release computer in the release build, and receives the output through the release computer in the release part – this is called the release build.

 

So what our release process needed was a piece of software that could easily create build processes for Websites, PS tools, SQL Scripts, SQL Reporting Services, SharePoint, and standard .NET code. These build processes must be able to be switched between the various builds above easily, and store information on what goes where and what comes from where depending on the build.

 

Sounds complicated right? Not if you use “insert catchy jingle here” FinalBuilder!

 

This program allows you to automate every single part of your release process, and when you use it with PS Tools, (Extremely useful for programming, find out about it here) you can run just about any script, on any computer in your network. Here’s an example of how useful it can be:

 

With each different build I have to do, I have to update a separate database. This means I have to run 4 different scripts on 4 different servers. Typing this out over and over again can be cumbersome. With FinalBuilder, I can set the server name and database name for the 4 different builds, and have the same line of code in the build do 4 different things depending on the build version.

 

Since it is all one script, this means that there is no complicated having 4 different scripts for 4 the different builds. It shaves a lot of development time from the release phase, which most software engineers would have to think was the most boring phase of the software life cycle.

 

Using this makes releasing much more repeatable, and saves time for the fun/important stuff, like design and implementation. So when you get the chance, check it out. It’s at http://www.finalbuilder.com/ . It’s an Australian company too, so it has got to be good!

Software - how to - make quick prototypes.

Straight from the Napkin to you! Thanks to http://www.snyderconsulting.net/article_paperprototyping.htm

who have a lot of good information on Paper Prototyping.

 

As I said I would do before, here are a couple of pointers that should hopefully help you if you developing prototypes for users unsure of what they want.

 

Prototyping model:

 

Basically, the prototyping model relies a lot on smoke and mirrors. Making it look like a finished product that barely works, but delivering the gist of what the program will do. Then scrap it, and do a quality version of the prototype, focusing on how the user will want to use the product.

 

Use asp.net for prototypes:

 

Because of this, I tend to use asp.net for prototyping. It provides lots of easy to implement asp.net controls, along with master pages and CSS, to make designing GUIs a snap. AJAX enabling it makes the website act just like a program on the hard drive too.

 

Before you start, design your GUI, then your master page

 

While the end users may not have any idea on what they want, you definitely know what they might want. You also definitely know how you want the application to look, and how the user would like the application to look. Plus, having something that looks nice makes the user think you are doing a good job.

 

With GUI's, a little planning goes a long way. Set you GUI with the same idea as Microsoft SharePoint Server. Have a Master Page, various layouts for entering, editing, etc, in your master page, and then individual set ups for your individual pages. This makes developing new functionality much quicker from the GUI side of things.

 

Set up the AJAX controls Toolkit

 

There is so much good code in here, and so much useable out-of-the-box functionality, you'd be crazy not to use it. Check out http://www.asp.net/ajax/ajaxcontroltoolkit/samples/ for the tools inside the toolkit, and http://www.codeplex.com/AjaxControlToolkit to download the toolkit. Installation is fairly interesting, look at the videos on http://www.asp.net/AJAX/ajaxcontroltoolkit/ to set up your toolkit.

 

When designing data entry or editing, use the DetailsView class

 

The DetailsView class is probably the easiest way to set up data entry and data editing. With a little bit of work, the buttons used to insert can be changed too, so it becomes easier for users to understand. Tomorrow I'll upload some code that changes the insert DetailsView into the relevant edit DetailsView when the user saves their data.

 

When you don't know what data is going to be needed, use the Table class.

 

The great thing about the Table class is you can easily set it up to look like a GridView class, but not worry about tying it to a Data Structure. You can also easily make the table look like input has been entered and show what it would look like when inserting data. I'll put up a picture of how this looks tomorrow.

 

More to come, this post is already too big!

Software: Using Multiple .Configs for Your Programs

So i've been trying to find a way I can change connection strings in an app.config or a web.config for ages now, and I finally found out how to do it today. All you need is one line of code in your pre-build event properties:

 

copy /Y "$(ProjectDir)"$(ConfigurationName).config "$(ProjectDir)"App.config

 

That. Is. It. (adapted from this site)

 

There are many, many other ways to do this, and I was using a damn class to sort this out for me before, which meant I couldn't debug my websites, unless I published them.

 

Sure, you will need a debug.config and a release.config and whatever.config for your other configurations, but this is much quicker than having the builder generate xml on the fly using msbuild.

 

So here's the steps to do it:

1. Create copies of your original App.config and rename them to the name of your different configurations.

2. Set the different configurations to what ever you need.

3. Put the above line of code in the pre-build events section of the project's properties.

 

When you build, the project will use the app.config that was just created to set all keys, connections,etc.

So that's how you can is use different .config files for your different deployment configurations. I know this'll save me a good half hour with every new release.

 

Hope it helps you. For more information on msbuild's inbuit macros (all the $ stuff) click here.

Technical info: Teaching Users.

This week and last week was spent installing and teaching users our upgraded EHR (electronic health record) program, and it took me back to my days teaching and talking to Americans when they arrived in Australia. They don't listen, can't read, and love the sound of their own voice. For most of the staff I work with, this is pretty harsh, there are some like that.

But rather than make this a whinge on users, I'm going to look at this and offer a few tips on how to best teach users how to work with new things.

Key Point

The newer a system is, the more senses you need to engage to teach it to people.

New user: tell, show, do.

Updated user: tell, show.

Let me know if you can engage smell into teaching, I want to see that in action!

But if that was all I was going to tell you about this topic, I would be failing my own guide, wouldn't I?

Manuals (Sight (Tell))

• Manuals for the most part will not get read. Whinge. Cry. Build a bridge. Get over it.
• If you are lucky, people will read the manual if they get stuck, so make sure the troubleshooting and problem parts are easy to understand.

Initial Training (Sight, Sound (Tell, Show))

• Go through all the functionality of the program in a logical, easy to understand fashion, doing the things that users are most likely to use. For example, if you are installing a CRM program, show the customer how to add a client, and how to add all the fields that a client needs. Showing off some random, but useful function will only confuse people.
• Start Simple in the presentation, and keep it simple. Advanced functions can be shown when you are installing the software.
• In presentations for training, don't give out the manual, people will read ahead and get confused. Instead, give out parts of the manual that really really must be read, at times when they need to be read in the presentation.

Installation and Walk Through(Sight, Sound, Touch, Speech(Tell, Show))

• Be prepared to go through everything again with everyone when you install the thing. Keep reinforcing the important stuff, and people will remember it.
• After you've installed everything, this is where you can go through advanced things the program can do, if you think the user can work with it.
• This is also a good time to go through bugs in the program you've found, and what to do in case they happen. It means you won't be assaulted with extra tech questions later.
• Get them to show you how they can use some of the functions and explain them.
• If they are a new user, this is where you can stop, else it would be good to go through a walk through and test.

Walk through and Test (Sight, Sound, Touch, Speech(Tell, Show, Do))

• If the user is a new user, then you want to go through the walk though of the functions, but you want to test the user on the functions as well. Doubly so if the user will be working with private or extremely important information.
• After the walk through, get the patient to show you how they would use the most basic functionality. Watching this is good, because it will help you understand what is confusing about the user interface, things that can go wrong with the program (leave it to a new user to completely screw something up!) so that you know for the future, and the new user's ability with computers.
• A good way to get users up and running is to set up a separate "test" version of the program which the new users can play around with and break as much as they want. Make sure the user names and passwords for the users are different from the "real" version of this program though.

Continual Tech Support

• Don't PANIC.
• Most of the time, the problems will be very small. Don't get angry at the user for bringing these up though, its you job to make sure they can use the system, and if they can't, it's your fault for not teaching it well.

And that's it!

Hope I haven't bored you and have been at least a little bit helpful. Please leave any comments or feedback. I'd like to know if these tech bits are useful, or how to make them more useful.

JET, Excel, ASP.NET and you - helpful tips.

Ok, So here's my first technology post. Figure I better make it a good one, and I'm pretty sure this will help out a fair few people. One of the major things that I'll be working on is an intranet for the company I work for. We are quite a small business so we're moving tech to get a lot of work automatically, which makes things much easier to manage.

One of the first things that I was meant to doing doing is a simple website that used impersonation that would allow users to click on a button to upload an Excel spreadsheet into an SQL database. This would run a program that would use JET to take fields of data out of the excel and put them into a database. Simple right? Oh man, I wish you were right. Anyways, here's a couple of things that will help others trying to use JET through a program over an intranet.

• First off, JET does NOT accept any type of hard-coded impersonation. Some one out there may be able to do it, but the vast amount of discussion boards say it can't be done. When using impersonation in ASP.NET, make sure you keep the "Password" and "Username" fields blank.
• Unless you want to open VAST holes in your intranet site, letting the ASP.NET account initiate a program through "process.Start()" is not an option, but what are you to do instead? K. Scott Allen has written a very nifty class that can start a process as a different user, getting the current token, or a created token. Very useful stuff!
• Then you need to set up your DCOM permssions so that all the users of your intranet can access Excel remotely. Do this by: (I'm on Vista and working off memory, will fix this up tomorrow.)

1. Go to Control Panel -> Adminstistrative Tools -> Componant Services.
2. Go to: Component Services -> Computers ->  My Computer (IF you are using the server via remote connection) -> DCOM Config -> Microsoft Excel Application -> right click and click on properties.
3. Click on the security tab. Then "Launch and Application Permissions" I think. Customise and edit the permissions.
4. Make sure your users are able to remotely and locally launch the application, local activation is also handy.
5. Ensure that the user running the process (Identity tab) is the "Lauching user". Interactive user means the one currently logged in. And JET can't work with any hardcoded users.
6. Reset the computer.

• Now you've got your process up and running, you think you'd be golden, right? Wrong. Since you are now using JET as a user - and not ASP.NET - you need to give the user all privileges that ASP.NET has. There is a Microsoft KB for it around here. Make sure you set the following permissions.

1. The user must have "Full Control" of the file and folder that they are getting the file from. JET likes to take a copy of the file to work on. ASPNET also needs to have full control of the website that is being run.
2. Also, running JET on a file on the shared drive is a bad idea. Copy it to a directory on the server. Saves read-write errors too.
3. The copy JET uses is always put in the <%Temp%> directory windows creates. This is usually C:\WINDOWS\TEMP. Your user needs to have read, write and execute access here.

After all that, there's a little bit of fiddling around to do, but it's different depending on how servers and permissions are set up, so there's not much I can write.

Well, that's the first tech post, hope someone finds it useful. Please post if you have any comments, ideas, whatever, please post them.