Didn't see that I had posted this so, I figured it was about time I did. I was approached by David Walker at the Community Leader Summit held in Dallas, TX to join the INETA Speaker Bureau and help them get a speaker focused Podcast up and going. I have been working with the Rob Zelt (INETA Live!) to line out some hosting details, but we are beginning make progress.
I feel very privileged and want to extend my thanks to David Walker and INETA for giving me this opportunity.
Keep watching for more announcements.
Technorati Tags: INETA
I want to take a moment to let everyone know that Randy Walker has received the Microsoft MVP for VB .NET. Congratulations Randy, this is well deserved. Thanks for all the things you have and are doing for the Northwest Arkansas .NET User Group and INETA.
You can check out Randy's blog here
Again well deserved!
Technorati Tags: Microsoft
I have been having an issue upgrading the DotNetNuke install for my church, so I thought I'd take a back-up and restore it on my laptop and then figure out what went wrong. If you have ever restored a back from a hosting server or just from a production environment to your local machine you have had this issue.
The reason for the problem is that the users that are defined in the database do not match the users that are in your current SQL Server install. You might find that you look at your server and see a user with the same user name but the GUID will not match.
Here are some SQL stored procedures that can help fix this issue:
List all the orphaned users in a database:
EXEC sp_change_users_login 'report'
If the user id already exists you can fix the GUID problem with this:
EXEC sp_change_users_login 'Auto_Fix' , 'user'
If the user id does not exists you can get the orphaned id created in the database with this:
EXEC sp_change_users_login 'Auto_Fix' , 'user' , 'login' , 'password'
I finally got it all worked out by adding the needed user to the server and then running the EXEC sp_change_users_login 'Auto_Fix', 'user' which produced the following output:
The row for user 'user' will be fixed by updating its login link to a login already in existence.
The number of orphaned users fixed by updating users was 1.
The number of orphaned users fixed by adding new logins and then updating users was 0.
Recently, Zach Young, a colleague of mine, and I started working on a project with the goal to learn several new things. I had the idea for the application, a simple web application that would displayed the post from registered RSS feeds sorted by publish date.
Which sounds pretty simple, but it became more clear the more we talked about it that we needed requirements. It is the same problem that is apparent in any software projects. I am, for this instance, playing the role of the customer, and I have a vision of a product I want someone to build for me.
The problem is getting this vision out of my head, where it is perfect, of course, and into a form that can be clearly communicated to the development team so that I can feel confident that what they deliver will be what I ask for.
I spent a few days diving into Use Cases and found that I didn't feel like I was getting anywhere. I was typing a lot of information but still didn't feel like the developer would get what I am saying. A quick phone call to another colleague, Raymond Lewallen and I was off checking out User Stories. And guess what they are small, light-weight, easy to write and easy to read.
So what is a User Story?
Well, according to wikipedia, A user story is a software system requirement formulated as one or two sentences in the everyday language of the user. This was exactly what I wanted. Since this is a side project and mainly to be used to learn, I don't want to spend all of my time writing tomes of requirements documentation before I get to writing some code.
Dan North: What's in a story
I decided to create User Stories following what Dan North has introduced in his What's in a Story post.
The simple format of the BDD style user story is quick to write and ubiquitous is easy to achieve. Let's take a look at the format.
Title (one line describing the story)
As a [role]
I want [feature]
So that [benefit]
Acceptance Criteria: (presented as Scenarios)
Scenario 1: Title
And [some more context]...
And [another outcome]...
Using this has allowed me to get the requirements documented quickly, in a form that both Zach and I can easily understand and we rarely have to go back over what is in the user story for a feature and could move on to learning how to write test to satisfy the user story.
If you are interested in checking out our project and looking at the User Stories we are developing you can find it at http://code.google.com/p/hermesreader. This project is intended to be an educational and you are interested in helping out drop me a line.
I will continue to post regarding the progress and concepts are are applying to the project as we tackle them. Hopefully this information will save you some time and help you get the code out the door.
Chris Tavares wrote a great article no creating applications with the ASP .NET MVC Framework in the March Issue of the MSDN Magazine.
Chris does a great job of grounding the reader with an understanding of the Model View Controller design pattern. The article also comes with a download code sample to help you get started.
This is the future of web development get a jump start with the article on Building Web Apps without Web Forms.