So apparently my site hasn't been up for a week, i have known.  I am so busy lately with a lot of personal stuff I was unable to rectify the situation.  The site is back up now and I am ready to start blogging again.

The main issue was that the dns record on the dns server got wiped out so the internets didn't know where to go :(

Sorry for the inconvenience.

At work me and a friend are about to start a new project and since both of us like agile methodologies we are wanting use our project as a test case.  Joseph knows more about agile than I do; so he is kind of my coach on it.  One of the things we are planning on using is BDD.  Since I am not to familiar with it I engaged in a conversation with him about it and this is the log of the conversation.  I hope others find it useful.  In some respects it is _using_ BDD to learn about BDD, in an abstract theoretical way that is.

me: yo I was thinking it would be cool to try and use our project as maybe a test case for agile dev work and if successful maybe other projects can move to a more agile dev process.  Like it would be cool to have a CI solution going

josephholsten: yes

also, behaviour-driven.org is perhaps better than the alternatives

me: yeah.  Is there like a 2 paragraph what is BDD so i can understand that more going into reading the site because i am getting confused right now and am only in the intro.

or maybe i just need to read the intro page 2 or 3 more times

josephholsten: say that again?

me: sorry, stream of thought typing isn't really a good idea hehe.

Was curios if there is like a 2 paragraph description of BDD.  I am reading the intro page and running in circles because I don't get it to well.  Was thinking if i could get a really high level overview i could understand the intro more.

josephholsten: ah. BDD is a pattern language, which is why you feel that way.

You'll have that same difficulty with
"Pragmatic Programmers" and all those other pattern languages

So, where to begin?

me: so should I read something on pragmatic programming first?

josephholsten: no, I was referring to a book with a similar style

me: ah

gotcha

josephholsten: BDD is a process to go from hopes & dreams to a product that fulfils them

you might call it a design process, but it's also a style of specification, implementation, and verification

The idea is to start with a sense of what's wrong. Then write some stories of how to solve that problem

there is a suggested template for the stories

me: so like literal stories?

josephholsten: once you have stories, you can look at all of them and say: this one's more important than that one. it should come first

well, yes.

but there tends to be a more rigid format, to help turn them into an implementation

me: ah

josephholsten: here's the page on stories

http://behaviour-driven.org/Story

but don't worry about it much, they use a lot of terms without explaining

so you want to have a product that can make these stories real

but you can't do everything at once, so you pick a few to start with

(it doesn't matter which. some people will tell you it does, and if they're paying you, listen. otherwise: smile, nod, and start where you think you should)

Once you have a few stories, you want to look at them in more detail

josephholsten: you write down examples of their behavior. You write examples so detailed that you can be certain of whether the product behaves properly or not

these are acceptance tests

josephholsten: they call them acceptance criteria

you with me?

me: sorta

josephholsten: okay

perhaps I should go slower?

Ah, right you don't see the point yet, or know where I'm going

sorry

me: :)

josephholsten: so, you start with a hope, then you turn that into a story, then you turn that into acceptance criteria, then you turn that into a behavior specification, then you implement the behavior

me: sooo turn the behavior into code? just want to be sure.

josephholsten: sorta

josephholsten: the thing about bdd is that it emphasizes working implementations over all else

so very often, every last thing I said you would write would not be as prose, but code

I write stories, acceptance criteria, and behavior specifications as code

that way I know if it

I know if it is real or still being developed

me: so lets see if i can repeat this how I understand it.l

josephholsten: sure

me: So first you start with the idea of your project.  What you want it to be.

Next you write some stories of how to use and not to use the idea.  Then follow that with what specifically do we need to have to accomplish our stories

josephholsten: yes

preferably only spec'ing a little at a time

josephholsten: then implement

so while you've got the theory in your head, let's make it real

'behavior specification' is another name for a unit test

me: so kind of like we want to be able to copy multiple lines of text would be a concept/theory then we would break that down into how it works as a behavior spec?

josephholsten: exactly

your spec begins as a description

me: so can we expand of the idea above as an example maybe?

josephholsten: "should print the text 'hello world' to the console"

me: ok

josephholsten: then you turn it into a test

me: gotcha.  so the ShouldUpdateProfileDataOverWebService

is the story in a unit tests and once we develop that we write the code to accomplish that story?

josephholsten: http://pastie.caboo.se/153892

it is a test, but it's of more than a single unit

josephholsten: working...

me: k

i'm still reading on the BDD site

josephholsten: so look at the updated pastie, and it's just a interaction behavior specification

you specify the state behavior or interaction behavior before you write the implementation

the same is true for stories

you start with a literal story

start with a title

"should greet the user"

then give it a defined narrative:

as an <English speaking user>,

I want <to be greeted when the program starts>,

so that <I know I can start using the program>

that's a role, feature, and benefit. respectively

me: ok that makes more sense now

josephholsten: like it?

me: yeah

i do that in my head just not so formally

josephholsten: exactly!

that's what I've been telling BJ for months

me: LOL I do that in all parts of my life actually.

Like when I want to go on a camp out.  I walk through a typical weekend and pack for each "event" that is going to happen like Getup so i need xyz clothing wise then pack everything.  Then I pack for the extreme cases just in case

josephholsten: the only reason to do it formally is when you aren't sure what the next step is, you can just do what the framework says

me: yeah I like it actually.

josephholsten: and hopefully not waste energy on things you don't need yet

me: yeah. and later you can maybe go back and cover the various use cases that are rare if time permits

josephholsten: which is more what we need from bdd

me: yeah.  It makes sense to me now.  Do you mind if I make this chat log a blog post?

josephholsten: well, not necessarily rare, but not as valuable

yes, please do

I'm planning on turning it into a presentation for tonight

me: k sweet it is a great walk through i think so if it helps someone all the better.

sweet

so i guess we helped each other.

do you have some info about your presentation I can maybe post on my blog so people in Tulsa if any are reading can go?

If you are in Tulsa and would like to here Joseph's talk here is the information on it.

http://tulsarb.org/
Bank of America building, 24th floor
Vidoop offices
6pm

Address:

15 W 6th St Suite 2400
Tulsa, OK 74119

I constantly revisit the thoughts on purchased products vs open source products and how they work in the business world.  I like Open Source Software because it is a great resource to learn from, but have noticed that there are applications that are really good with few developers.  That alone causes a support issue when something breaks.

Purchased Software

Usually with purchased software you buy the product and expect, and usually get, reasonable timely support when something goes wrong.  If it is from a small ISV usually you get better support and if it is a bug they tend to get an update for the bug fix out relatively quickly.  Since employees there are paid to work on the product there is constant forward movement, usually, on iteratively released software.  Generally you know what to expect with most companies especially when purchasing from a reputable company.

Open Source Software

With OSS you generally get a good product, but with one caveat.  You never know what support is going to be like.  I have used several OSS pieces of software and on a few have extremely awesomely cool support.  Most it is generally mediocre at best if you can get the main devs to even listen to the problem you have.

Then you have the projects that make me hate OSS people where the support is so horrid you don't want to even try to use it even though it is the only option.  Basically, if you have a problem you get an RTFM, learn what you are doing newb, or write something up on it so others can learn.  None of these actually solve the problem at hand and just lead to really piss me off.  And updates from these proejcts are usually a "I'm not paid to do this so you get it when you get it" type attitude.  To me this is bad for the OSS community and why I stay away from a lot of OSS products when considering something for the business world.

The Communities

Behind good products are usually good communities that offer support to others, this is good.  However, community support should be backed up by a good core support team whether it be the company/dev team from a purchased product or the dev team of the OSS project.  If there isn't either than you can run into bad attitudes and problems.

I find that people don't mind purchasing software because they can get good support from either the company and/or a great community, but they will not use OSS software because they can't be guaranteed what type of support they will get.

Utopia vs Life

I have noticed an increasing number of people lately who get into the "OSS for all" type attitude and that proprietary software is evil.  While I can understand where they come from this is a dangerous line of thought because it leads to people with bad attitudes towards feature requests or questions on updates and direction of a project.

On a few projects I have seen people ask if a feature will be implemented and a usual response is "write-it yourself".  Yes, this would be wonderful if people would or even could  do that on their own.  Or they ask what direction a product is going because they are interested in it; then when they find out it doesn't go the way they want it to they ask why not do this.  This sometimes leads to a "You can branch it and take it that way, but we aren't going to bother".  Point being is they were just curios and they got stuck with a "piss off" response.

Conclusion

Basically, what I am getting at is with purchased software most people understand what they are getting into, and don't question it because it has always been this way.  However, with the recent push for OSS the last few years to break into the corporate world it is leading to a lot of animosity between business people and OSS dev's.  Honestly, some OSS people need to pull their head out of their asses and realize that OSS isn't a utopia they think it is and isn't going to be.  Business people need to shut the fuck up and realize that you are in a different time when it comes to software, and just because you aren't paying for it doesn't mean it isn't a good product.

If we can get OSS people to be more reasonable about development and business people to be more patient when dealing with OSS products things could go a lot further and cool things could happen.  We could even get some great "synergy". ;)

 

p.s. this was a stream of thought post that has been brewing in my mind for the last few months.  Please, leave comments on this if you want.

One things that has always been utterly confusing in ASP.NET is the dang Web.Config file.  For the beginner to ASP.NET it makes next to no sense and Visual Studio adds a whole bunch of stuff to it that I have no idea what it does.  It is also so odd and confusing if I want to do basic config stuff in my application I have no idea how in the world to go about it. 

Partly out of necessity and partly to rid myself of not knowing how the web.config works I have been spending time learning about it.  I am first starting out with the basics.  Getting something to work.

Getting Started

With most things I want to learn I completely bypass the "how" at first and get something basic to work, which is usually a "Hello World".  That is what we are going to work on in this post.  Lets just see something work.  So these are the two objectives:

1) Set a configuration option we can use in our code
2) Allow for debugging our ASP.NET application

Now, we don't "need" a web.config to run basic .aspx pages, but if you want to anything more advanced than a one page site then you will need one.

Web.Config

Here is our web.config that we are going to look at today.

This is really all we need to set a configuration option to access in code and to allow for debugging our application.  Please notice that everything is wrapped in:

<configuration>
</configuration>

That is important to note because all your config information should be under the root configuration node.

Custom Application Configuration

Next we have where we will set configuration options.

<appSettings>
     <add key="Hello" value="World" />
</appSettings>

In the appSettings is where you will put configuration options that are like global variables to your WHOLE asp.net application.  So in this case you will access the Hello key and it will return the world as its value.  So the code you would use to access the config options is:

You will use ConfigurationManager object which access all the information in your web.config file.  Since the Hello key is in the <appSettings> node then you would use AppSettings collection to access what key value pair you need.  In this case accessing hello and it returns world.

Why would you ever need to use this? Well one things comes to mind.  You might have a membership system that you want to turn on and off so you could have in the web.config:

<appSettings>
    <add key="Membership" value="false" />
</appSettings>

In your code you might have it check to see if it is true or false if true then it displays login stuff for people to register and login if false it doesn't display it. It might look something like:

If(ConfigurationManager.AppSettings["Membership"] == "true")
    //display login control

This is just a possibility of something you might want to do.

Debug

<system.web>
    <compilation debug="false" />
</system.web>

Here we set whether we want to debug our application or not.  I usually set this to yes as I have yet to write a bunch of code with out a bug.  All you need to do is to change false to true and you will enable debugging in your asp.net application.

Conclusion

The web.config file is actually a little more simple than it appears once you understand more of what is going on with it.  If you take learning it slowly and one little step at a time it is quite possible.  I hope to cover a little bit at a time of the web.config as I learn more and more since it is quite important to learn.

I normally don't post stuff like this, but sometimes they are just too good not to. Enjoy.