Wunda's World

The ups and downs of it

noreply@blogger.com (wunda) — Mon, 21 Sep 2009 18:30:00 +0000

Kaylee came home on Friday. I had no choice but to run around with her. It was great medicine! I missed her terribly and was so glad to be her #1 go-to person!

Saturday was rough.

Emotionally and physically, Matt and I were drained.

There was a lot of crying, doubt and fear.

It happens on this roller coaster of cancer. Remembering it will pass and I will feel healthy again was more than difficult.

Sunday was a turning point.

I ate well.

I drank a lot of water.

I laughed a lot with good friends.

And I shaved my head!

I feel like Natalie Portman in V for Vendetta.

I also had a great acupressure/reiki/massage session with Vanessa, my sister in law. She found a ginger tea that I love!

I felt reborn in positive energy and spirit.

And just in time, because Sunday night I left my family once again to stay at the RMH and resume treatment.

So, here I am.

I continue on my path of what seems to be most resistance, savoring the good days and pushing through the bad.

First cycle complete

noreply@blogger.com (wunda) — Wed, 16 Sep 2009 15:02:00 +0000

A bunch more to go...

I'm now recuperating at home.

The chemo made me very ill. I'm still feeling it. I have hardly gotten out of bed the last few days.

Every day I'm a little better. I hope to go for a walk today.

Its hard to believe I'm going to go back next week.

But every week done is a week closer to being cured.

This week off has been especially hard because Kaylee has the chicken pox. She has to stay at her Grandma's until she is all better. I haven't seen her in over a week. I am beyond sad.

I hope to see her before my next treatment cycle. Her little hugs, giggles and smiles are the best motivation and cure for this cancer patient.

One week down

noreply@blogger.com (wunda) — Tue, 08 Sep 2009 19:12:00 +0000

After only one week I can breathe out my nose.

I smelled flowers on the street.

Chemo certainly knows how to kill.

Unfortunately it does not distinguish cancer.

But today starts a new week and I'm feeling better.

My body knows how to heal.

Giving up a year of my life

noreply@blogger.com (wunda) — Sat, 22 Aug 2009 11:48:00 +0000

To save the rest of it.

That's what the doctor told me I have to do to cure this cancer.

I have a daughter that will need me in her life, so that is the plan.

I spent the past week at Sloan. Taking tests. Speaking with doctors.

And crying... a lot of crying.

It is a surreal experience. Trying to understand the complicated schedules and make sense of how my family can manage life without mom.

And not just without mom. Life with a cancer patient.

I'll be treated as an outpatient at Sloan on a clinical trial.

My treatments with be 3 week cycles of chemotherapy for about a year. Typically the cycles are 2 weeks of treatment and 1 week of rest. During my week of rest, I will have to go in for tests.

When I have radiation, it will be 6 weeks with no break. This does not change the chemo schedule.

Some treatments are an hour. Some are ten.

I live about 1.5 hours away from Sloan with no traffic.

So every day is 3 hours longer, just for driving. Probably a little more.

3 hours of being stuck in the car and potentially very ill.

My initial reaction was defeatism.

My next reaction was complete and total fear.

I have a daughter and husband who need me. Who love me.

I am determined to make this work.

I will stay in a hotel on the long days.

I will coordinate a schedule of driving with my family and friends. I hope to have enough people to call when I cannot make it to the city and someone will help.

In the event that falls through, I will use a car service. The sustainability of this option is low for its cost and the emotional drain of being alone. I hope it is a rare thing.

I will sleep in my own bed. I will get to see my daughter and husband everyday.

I will remain positive and strong.

This year of my life. The year I had cancer. The year before I was a cancer survivor starts now.

Talk about rare

noreply@blogger.com (wunda) — Mon, 17 Aug 2009 16:42:00 +0000

The morning has been hectic. First, I went to the ENT who did my surgery (and found my lovely growth) to remove the packing in my nose -- 6 feet of guaze!! I feel about 100x better!

My husband, Matt, and I went to breakfast and mid coffee found out I have embryonal rhabdomyosarcoma. A rare childhood cancer. Weird, right?

Living in New York, I am lucky to be close to Sloan Kettering hospital and thankfully they have an oncologist who specializes in this cancer. He happens to be a pediatric oncologist but I'm a little woman, so I should feel at home with the kid size chairs :P

Matt is dropping off the pathology today, and hopefully by my appointment on Wednesday we'll have a plan of action.

wunda's world upsidedown

noreply@blogger.com (wunda) — Sat, 15 Aug 2009 12:55:00 +0000

The last few months I've been battling sinus problems.

First guess was an infection, but the antibiotics did not help. My dr thought I needed a longer rx, but since we weren't sure it was infection, I opted to wait and see. Allergies were also a possibility.

Some days, I felt broken -- though I figured running after Kaylee and getting little sleep were to blame.

I went to an ear, nose and throat dr last Tuesday.

He took one look into my nose and his reaction was distressing. I don't remember exactly, but once you hear cancer, you don't hear much else.

He said the chances were small, but we should do testing quickly, to alleviate any fear.

That day I had a CT scan. That afternoon he called and brought my husband and I back to the office.

The results were easy enough to see -- the sinus cavities on my left side were filled. He said it looked a lot like an antrochoanal polyp (one side and really big). It could also be a fungal infection... and of course the possibility of cancer was looming in the room.

One thing was definite. It was big and needed to be removed.

Surgery was scheduled for Friday. He would do a biopsy and then depending on the result, stop or remove the benign tissue.

As soon as I woke up from surgery, I asked the time -- one surgery would be longer than the other... It was less than two hours. My mom and husband were by the bed and someone told me it was malignant.

Although my first reaction was "are you sure?" I was calm. The fear of what could be was replaced with reality. Cancer. I was not surprised. I had all week to prepare. I'm sure the drugs from the anesthesia helped me stay calm.

I've known many who have battled cancer.

I lost my father, my husbands aunt, my uncles wife, my grandfather, my sister's mother in law.

I know survivors too -- two uncles, my aunt, a few friends, parents of friends.

What are the chances I would be added to the list? When I was a little girl, I was a bit of a hypochondriac. I was always worried I had cancer. As I got older, my fears subsided.

When I went to the doctor last Tuesday, the last thing on my mind was cancer. I had just given birth and nurse my baby? How could a diseased body support such miracles?

I will know more about a diagnosis on Monday. The weekend is going slow.

I am nursing my daughter as much as I can. The idea of early weaning is heartbreaking. I fear she will grow up without a mother. I am thankful she is only 1 as she will not remember. She may not remember me. I hope I can live on in her through the bonding relationship we've created and the stories and memories people around her hold close.

And of course, I am not calling it quits -- I don't even have a diagnosis, or 2nd opinion. My strategy is the same I used to run a marathon. If I felt tired, in pain or I couldn't go on, I would ask myself, "can you finish the next mile? just up to that next tree? will you be disappointed if you stopped because you know you had it in you to keep going?"

As long as there is a chance (even a fools hope) and I can make it to the next tree, I will. I will come through this a survivor, regardless of my mortality.

I am scared. Writing is an easier form of communication. I say the word cancer with tears in my eyes and a closed throat. I write it with ease. I am thankful for this outlet.

Ensure test coverage when refactoring to mocks

noreply@blogger.com (wunda) — Fri, 07 Aug 2009 14:45:00 +0000

Using real dependencies in your tests will lead to pain. A lot of pain.

Most likely, your test fixtures lack coverage, test the wrong class, be difficult to read and don't do what they say.

Eventually, your team will decide to abandon testing or introduce mocking/stubbing.

Refactoring your existing tests will be a major endeavor.

It will be tedious and repetitive.

You will feel like you are wasting time.

You will have a strong urge to rush.

To help you out, I've outlined the steps needed to refactor a test to mocks. I've noted steps that are easy to skip (yet still important) with *

1. Make a copy of the TestFixture -- call it TestFixtureNameWithMocks -- this will ensure you do not lose test coverage and can commit often.

2. Comment out all tests

3. Delete the setup code

4. Take a moment to read the first test

Does this test actually test anything? (if not, figure out what it should be testing and get it working right in the original fixture first!)*
Does it verify state of the CUT?
Does it verify state of a dependent (or dependent of dependent of dependent...)?
Does it do more than one verification?

6. If there is more than one verification, determine how many tests you actually need.

7. If your test relied on the state of a dependent, verify that behavior is tested in the correct test fixture (i.e. the dependent's!). If not, you need one, use this test as an example. Create a failing test now, before you forget. If you have a rabbit hole of dependents, make a test for the top dependent.*

8. If needed, break out the test into multiple verifications -- select one to do, comment the rest.

9. Uncomment test and rewrite using mocks/stub. You will find that some tests are quite different. Some similar. Some will require refactoring of the CUT or dependents to make mock friendly.

10. Run the test and verify it passes. If it does not, figure out what preconditions are missing -- check the CUT and old test. Keep doing this till it passes.

10. Comment out code that is being tested.*

11. Run test, verify it fails for the right reason. If it does not, check the test and verify your assumptions. Make it fail for the right reason!*

12. Uncomment code, verify it passes. If you didn't change code in 11, you can skip this step -- I am paranoid and usually do it anyway :)

13. Repeat for every test in the fixture (and any new tests you find). Pull out common setup if needed. Rename tests since the original names will most likely need it :P

14. Remove old test fixture and rename new one.

If you made it this far imagine how long rewriting one test takes. In the best case you still need to run each test at least 2 times.

Now imagine doing this for more than one class.

How about for how many tests exist by the time our tests are painful enough to require this change.

If done right, this will take a lot of time. If we do it wrong, we take great risks and have tests that give us a false sense of security.

Clearly, if we want to continue delivering end user value, we cannot do this all at once.

Here is one way to do this:
1. Whenever a test is updated (bug fix, enhancement, refactor), update the test fixture to use mocks.
2. Have a policy where it is ok to have 2 fixtures for 1 CUT (one with mocks and one without) to encourage people to start using mocks w/o the overhead/context switch of a big refactor. Stress that finishing the refactor takes precedence over starting new work.
3. Let everyone on the team know that it is expected to take time and include that in commitments and estimations.
4. Remain disciplined

Good luck!!

Adding to the team

noreply@blogger.com (wunda) — Thu, 30 Jul 2009 16:13:00 +0000

We've all felt the pain of the interview process.

It sucks. And its not just the candidates out there. Its also the way we find them.

Typical Procedures:

Recruiter or ad
Phone interview
Written questions or code samples
In person interview
Meetings with other team members
References, background checks, drug tests, security clearance, street fighter challenge

There certainly is dysfunction here. Many interviews feel like a game and its not played well (or fair).

I think of finding a new team member as a process of filtering:

The process is a series of filters each more fine than its predecessor
A filter should have definite output
Good people are difficult to find. Too fine a filter early in the process is a risk
Most filters have manual steps. Filters that filter too little are a risk.
Finding the right person is personal to the team, so any filter that does not involve a team member is less accurate
A good fit is unique to a team, so rarely will the same sequence of filters fit multiple jobs.
Some criteria may give someone a pass around filters -- personal recommendations, proven methodology expertise and already working for company are a few examples

Before we can setup our filters, we need to know our goals for a candidate. This is a lot harder than it sounds. You may find you don't really know your "goals" beyond a "senior" developer who is a "team player" and "experienced" with our technology and methodologies.

Once we know what is important, we need to figure out how to filter this behavior. We must also look at a persons ability to grow into a goal and the team's desire to teach (which will be biased depending on the person).

Example:

Goal: We want someone who is an enjoyable pair programmer
Importance: We only pair so friction here is best avoided
Ability to Learn: Developers, like all humans, are known to be stubborn in changing their personality. Though people can come around.
Ideal Filter: Spend a day pairing with them, switching people so at least a few team members weigh in

Clearly this is not a recommended starting point, unless you want to have a stranger on your team everyday poking around in some code in your project. Or maybe it would work if you have a lot of spikes?

Now what?

We can dig deeper into this goal:

What kind of traits make someone a good pair?
Are there ways we can define questions that will clue us in on these traits? Do any of these questions have answers that we can entrust an outside party to interpret?
Can we use their past work experience to help?

If we find this goal is best saved for later in the process, we can move on to goals that are better found at coarser levels. Do we required a certain amount of experience or schooling? Do we want people from a similar background (domain, technology, methodologies)? Do we care if they change jobs a lot? Too little? Are they active in learning new technologies? Are they interested in our methodologies? Do they live nearby?

We may not care about individual answers to pass judgment, though a combination of answers is sure to give us something.

How we find people to review is also a filter. If we want someone who is involved in the community, we can use those channels to find people either passively (twitter we're looking, ads on blogs we like) or more actively (read blogs and tweets to find people, find people working on open source projects).

Remember, its not just what you want, its what they want. Make sure your job description includes things that will attract the good fits (or have some people running to the hills), like weekly book readings or Star Trek Fridays.

Finally, there are unique things at every environment. What attracted the team there? What are team member strengths and weaknesses and what is the state of the project -- how can a new team member help most? Do we need another good pair or is it more important we get someone who can help us fix our data layer and quick.

Finding a good fit is a lot of work. If we spend the time to figure out what we want, we can figure out better questions and ways to find them. I'd say its a good exercise, even if its not quite possible to create a systematic filtering process.

Off topic, I'm in favor of speed dating style of interviewing: open house at your company, each team member gets 7 min with each person who shows up. Anyone with all yays moves on to the real interviewing. It may waste a day of everyone's time, but I bet it would be fun and if it worked, it would save a lot of money on recruiters, ads, phone interviews, code reviews and spending time figuring out what "questions" will help us find the best fit.

Can't seem to ever finish a post...

noreply@blogger.com (wunda) — Thu, 29 Jan 2009 20:54:00 +0000

Between working and mommying, I can't seem to finish any of my blog posts -- this is bothering me...

So, I signed up for twitter -- wundarous

Maybe I'll get some ideas out...

or maybe it will be random thoughts that make no sense..

Either way, no excuses not to add a sentence here and there!

The need for speed

noreply@blogger.com (wunda) — Wed, 03 Dec 2008 14:44:00 +0000

I say this a lot, but I love TDD. Besides the list of reasons about how it improves code or simplifies solutions, TDD is fast.

TDD is fun because it goes so quickly. Write a test, make it pass, refactor, run more tests.

I love the flow. I love adding a new interface and using it without worry about implementation. I love knowing after I make a new test, something in the app is different and it works. I love living in the tests and only running the application before checking in.

However, the moment the tests slow, the practices start to slip...

Writing code and verifying it works by launching the app, then creating the tests
Making the test pass before verifying it failed.
Not running all the tests before check in.
Not refactoring because it takes too long
It stops you from working close to 5 because you don't want to wait for the build
Not adding tests at all because you don't want to break the build and don't want to wait to find out
It ruins all the fun.

These things all lead to poor test coverage or tests that don't actually do what they say. Yeah, on paper your coverage may look nice, but there's plenty of code you can delete w/o breaking tests. Coverage makes sure a code path is followed, it does not verify the path was actually tested.

So, how do we keep our tests running quickly?

Mocking. Reduces the amount of time spent creating dependencies and their dependencies and the rabbit hole of dependencies that nobody can even see.
Use a one to one ratio of test assemblies to application assemblies -- don't waste time waiting for things to build that you're not testing.
Keep interfaces and implementations in separate assemblies. Dependents should only be recompiled if the contract changes, not the implementation. This allows you to complete the usage of a change, without worrying about the implementation. Sure, you can just resharper, but are you really going to add tests for a new method right now?? If you do, you break the rhythm, if you don't, you have to remember, somehow, that there is code that needs to be implemented somewhere that your tests won't pick up... you'll start thinking about the implementation or just forget and break the app without anyone knowing.
Simplify. Keep tests short. Only create items in setup that are used in all tests. Avoid factories for creating concrete classes because they hide dependencies and make it too easy to use real implementations instead of mocks. Avoid repeating yourself in tests, don't assert the same thing twice, it doesn't help to have the same failure twice but it does slow everything down.

In general, follow the best practices of test writing! They're there for a reason. No point in experiencing the pain of the nice people who figured them out. Take advantage w/o having crappy tests, lots of pain and failure.

When Agile Works

noreply@blogger.com (wunda) — Wed, 26 Nov 2008 14:49:00 +0000

When I started consulting on an "agile" team back in February, my first thought was, "Hey! You guys lied! This isn't agile."

The working practices were reminiscent of James Shore's recent blog post.

There was Scrum but they lacked visibility, risk mitigation and self management.
There was a morning stand up, but it was a status meeting with over 20 people -- mostly watchers.
There was a single product team, but members were broken up into domain groups with their own managers, politics and definitions of success.

There were bad practices, communication breakdowns, over-commitment, over-time, half finished features, inconsistency and plenty of technical debt.

Team members had all the stress and no power to change.

But, there was hope.

Within the first few months the company reorganized and moved towards product hierarchy eliminating the contention between groups.

=>Consistent goals and priorities.

The BAs, design and product owner worked closely with an agile coach to create a product backlog. They began having sprint reviews and retrospectives.

=>Visibility and reflection.

A few people became scrum masters. A few others scrum product owners. They started going to agile conferences and local meetings.

=>Engagement.

I left at the end of July to have Kaylee. Things were changing, but we were still far from a well functioning agile team.

When I returned in November, I heard that our agile coach said this was the best agile team he's been on.

I thought to myself, "I think he's been drinking some kool-aid..."

However, when I came in for sprint review and planning, I was amazed.

So much changed.

Team members were involved.

Practice improvements and innovations were made throughout the day.

Charts and metrics were used, not shown.

People were having the right conversations.

The differences not only showed in the team and interactions, but the product.

They had visible success.

I feel very fortunate to have the unique look into the evolution of this agile team.

When you are on the team, it can seem like things don't change. Our retrospectives are a microscopic view compared to a projects lifespan. If I was working for the past 3 months, I may have not noticed.

Maybe a periodic review of how things were/how things are would be a good motivator and illustration of how cool agile can be when its working.

3 Months Later...

noreply@blogger.com (wunda) — Wed, 12 Nov 2008 15:44:00 +0000

Almost.

Babies are challenging... Giving birth was easier... Forget about the note I was sleeping better after Kaylee was born, that didn't last long!

Ah, but the human condition. We adapt. Disrupted sleep included.

Now that I've adapted, I'm consulting again.

Apparently, I really, really like to code AND its much, much easier than being a mommy! Not quite the same ROI...

Since I do most of my work from home, I get the best of both. I'm quite lucky.

I'm with the same company and working with lots of WPF and TDD. We just started using the Isolator AAA from typemock, which looks nice. I know Roy was very involved with its creation and I usually agree with all his testing methodologies :)

My heart is still with rhinomocks, but hopefully I'll find a place for typemock too!

And being a mom, I have to include some newer pics of my lovely daughter!

My Little Wunda

noreply@blogger.com (wunda) — Tue, 19 Aug 2008 14:47:00 +0000

I'm proud to say I'm a mom to a beautiful daughter born Saturday, August 16th. I'd like to thank my great birthing team of my husband, Vanessa (his sister) and my doula, Amy. Between them and hypnobabies, I was able to have an incredible birthing experience!

To keep up with the academic nature of this blog -- I'd like to share what I've learned so far in my few days of motherhood (note, I never picked up an infant or changed a diaper before Saturday)

1. Giving birth was the most intense, satisfying and romantic experience of my life
2. Its better to let your dog lick your infant than a person kiss their face
3. There's all kinds of great feelings for your own child you could never imagine
4. Wearing your baby is lots of fun and lets you do something while they're sleeping other than watching them sleep
5. Its still early, but so far I've been sleeping better than I have in the past few weeks (my husband however, is learning the joys of interrupted sleep)
6. Every person you talk to will give advice and everyone has different opinions on the same things (that goes for doctors, nurses, grandparents and strangers)
7. Babies like loud noises, cry before they go to the bathroom, fart louder than you could imagine and produce incredible amounts of poop!
8. If all you do is breastfeed, change diapers and sooth an infant, it can take you days to write a single email
9. In a single day, your entire outlook, appreciation and viewpoint changes completely
10. Every coo, cry, movement, poop and breath from your infant is precious

Although I'm sure I'll have my hands full, hopefully, I'll get to write some of the posts I had been putting off for the last few months while I'm away from work -- I've had a lot of adventures in WPF and TDD I'd love to share!

TechEd Pair Programing Session Overview

noreply@blogger.com (wunda) — Fri, 06 Jun 2008 15:22:00 +0000

Since the session environment was different from our usual, and the audience's agile experience varied greatly (mostly none or little) we decided to allow the audience to ask questions during the presentation. The most successful pairing environments leverage a strong agile environment, so much of our content relies on certain knowledge of other agile practices.

Since we didn't limit questions we ended up covering the first 5 slides and lots of questions in the first 45 minutes of the class.

Not exactly the definition of a breakout session.

This made some people very happy and some people, well, not.

If you enjoyed the session, I'm really happy it helped! I hope you gained some insight you can take back to your team and good luck!

If you didn't, I hope you left early and gained interesting knowledge elsewhere you could take that back to your team and also, good luck :)

Joe White has posted a great summary of everything covered -- thanks Joe!

Most of the questions we answered would have been covered during the lecture, so if you are worried you missed out on some important information, no worries, you just got it in a different order.

Followup to Testing with Mocks

noreply@blogger.com (wunda) — Fri, 06 Jun 2008 14:17:00 +0000

Thanks to everyone who came to the Testing with Mocks TLC session at TechEd.

Here are some links of things we touched on during the class. Please leave a comment if I missed something :)

Test Smells:
TDD Anti Patterns -- Be sure to read the comments, there are some valuable smells there too!

Books:
The Art of Unit Testing
Working Effectively with Legacy Code
TDD by Example (Kent Beck's book)

Rhino Mocks:
Ayende (creator of rhino mocks)
Google Group
Reference Guide

Other .NET Testing Frameworks:
nMock
TypeMock
Moq

Test Runners:
nUnit
mbUnit

Tools:
Resharper
TeamCity
CruiseControl.NET
CruiseControl.rb

IoC Containers:
Castle MicroKernel/Windsor
Spring.Net
StructureMap

Community:
Alt.Net

I feel like I'm taking crazy pills..

noreply@blogger.com (wunda) — Wed, 28 May 2008 20:10:00 +0000

Today, I was trying out a wpf grid control and couldn't figure out how to style or data bind or do anything with it in xaml.

I sent the sales rep an email asking for some examples and I was told data binding, templates and styles were not currently supported (dependency properties it seemed too).

With that, I thanked them for their time, and said databinding and styling were a priority so we could not consider their grid.

I didn't expect to hear much after that, but I was informed that those "bells and whistles" were not as important as the other features only their grid supports...

While I would argue these "extras" are a foundation of WPF, I don't think that should matter.

Why are my priorities not valuable?

When listening to user feedback on our applications and products, we can get defensive.

We're all human and insecure, so I guess that could explain it.

However, I would rather focus on a different issue -- what is guiding our decisions, priorities and emotional responses?

Why is the response to user feedback a reason instead of thank you?

All feedback is an opportunity to create a better product. It is great service your users provide (usually for free!).

One of the greatest technical challenges in Ript was adding the ability to rip Flash. It took many, many spikes. I think most other companies would have put it aside -- it didn't add much value, wasn't going to make us money, isn't something that will make a person use the application and certainly cost time and money.

So, why did Gerry make it a requirement?

During user testing, we noticed people thought they were doing something wrong when they couldn't rip flash. They don't understand that some images are flash and some are images.

Gerry could have said document how to determine if an image is Flash so users will know why they can't do something.

But, she understood that it didn't matter if the behavior was documented. If a person thinks its broken, begins to lose trust or feels they are doing something wrong, they are alienated. They will not feel confidence in themselves or the usefulness of the program.

Before working with Gerry I didn't understand this concept. I would have put flash aside. However, her decision is what made her a great product owner.

Where I'm going, where I've been

noreply@blogger.com (wunda) — Sat, 05 Apr 2008 11:30:00 +0000

I'll start with the where I've been:

After NBC took over Oxygen, our lovely, little agile group got a bit... lost. We lost our product owners and inspiration and little by little, we found other opportunities and now, there is no more group.

Next, I went on to an agile coaching role. While bad experiences can inspire the best writing, this was not the case. I decided to resign quickly.

That leads me to my next bit of news -- I am 20 weeks pregnant. I want to spend every week before embarking on motherhood on a worthwhile and fun adventure!

So, where am I now?

I am consulting in NYC on a motivated and talented team working on WPF applications. Its great to be back in this space!

Where am I going?

No idea. From what I hear, into sleepless nights! I plan on working after the baby, but nothing is official at the moment and I'm happy that way.

What about the hot agilistas?

No worries! Oksana and I will still be at TechEd in June. Pregnant women are hot too! Seriously, 7 months pregnant in June in Florida! Who plans that?

Painless CI?

noreply@blogger.com (wunda) — Wed, 12 Mar 2008 20:01:00 +0000

I recently started a new project and had the fun task of getting the build server up and running. Usually, I dislike the entire process -- creating a nant script, configuring cruisecontrol... so much xml... so little fun!

Since its a new project, first order of business -- rake for builds! Something we experimented with at Oxygen, but didn't add to our practice. If you have the options of putting ruby on your build server, switch to rake if you are not already using it. Its easy to read, easy to build projects and you can reuse code. Such a nice change from the copy and paste nightmare of nant.

After spending 1/2 a day working on cruisecontrol.net and trying to figure out what configuration I needed, I realized -- hey, you can use cruisecontrol.rb -- ruby is already on the build server and we're using rake.

I'd post directions on the extra steps or setup I needed to do, but the directions from the cruisecontrol.rb site left me with a working build -- imagine that?

Tech Ed 2008

noreply@blogger.com (wunda) — Mon, 18 Feb 2008 21:50:00 +0000

Oksana and I will be speaking about pair programming and using mock objects at Tech Ed 2008.

Register for Tech Ed here

The conference is in Orlando in June, so bring your bathing suits!

Gerry Laybourne on agile

noreply@blogger.com (wunda) — Thu, 24 Jan 2008 17:42:00 +0000

From an interview with Gerry (page 6, scroll about halfway down the page):

"...And through that, I really got to know them and decided that I really wanted to understand agile management—which is a very interesting way of managing. It's a very formal discipline that allows the team to own the work. And what happens in software development is that you can give an assignment to a software-development team, and then six months later, they deliver what the assignment was. And you look at it and say, "Oh no, that's not what I wanted." In agile management, you work on a two-week cycle. You're working. You have a "scrum master." You have priorities set. You agree on what the priorities are in the meeting. You review the priorities. You evaluate where you are, and you move to the next step..."

I love that she knows agile is a "very formal discipline."

Because laughter is good for you..

noreply@blogger.com (wunda) — Thu, 17 Jan 2008 00:08:00 +0000

Human tetris anyone?

Nothin but WPF

noreply@blogger.com (wunda) — Tue, 15 Jan 2008 15:00:00 +0000

As you may have read on Boodhoo's blog -- in addition to Nothin but .NET bootcamp, he's introducing several new topics including Nothin but WPF, which I am teaching.

The first Nothin but WPF will be March 24th - 28th in midtown NYC. This class is completely focused on WPF and XAML and will include DataBinding, Styles and Resources, Custom Controls and plenty of other topics to keep us busy :)

You can register for the class here

Go here to see the current Boodhoo training schedule for 2008 -- he'll be adding more classes and an rss feed so check back for updates.

Ript video

noreply@blogger.com (wunda) — Sun, 02 Dec 2007 14:19:00 +0000

There is a funny ript promo available for your enjoyment. Check it out!

Mass Effect or Rock Band?

noreply@blogger.com (wunda) — Wed, 21 Nov 2007 17:21:00 +0000

That is what I said to myself when I got home from the store yesterday.

Decisions, decisions...

I started with Rock Band -- we had a full band waiting to play (myself, husband, sister and brother-in-law). I needed to set everything up before they came over. (i.e. I wanted the drums all to myself)

Having 4 friends rocking out is really a blast! My sister thinks we should dress up and do a show on Thanksgiving for our family. I'm not sure, will they appreciate our musical talent?

Can someone tell me how to stop playing the same songs over and over again? If I have to sing In Bloom one more time...

My sister and her husband went home after a few hours of rocking and it was on to Mass Effect. It looks great! Only problem... How do I play? KOTOR is one of my favorite games of all time and so far this game feels more like Halo than role playing... Need to work on using powers better... I figured out the equipment screen though!

I couldn't agree with Penny Arcade more :P (read all 3)

Whatever happened to sustainable pace?

noreply@blogger.com (wunda) — Wed, 21 Nov 2007 16:20:00 +0000

Who practices sustainable pace?

Development is an art. Its a mental challenge (emotion if you pair). As a day goes by, an individuals definition of quality changes depending on their mood and energy.

Over short periods of time a team can keep up long hours; especially if there is positive momentum or results in sight.

But permanent hours to get more out the door? Does this really work with out sacrificing quality and practices?

How many times are corners cut to meet a deadline? Was it ever too much to write that test first? Was code copied without refactoring to remove duplication? Is there spike code in production cause it worked?

Is that our risk to take?

Can a person control burnout or realize the compromises they make? People have an amazing ability to adapt to any situation. In a bad situation, we forget, we lie (mostly to ourselves), we ignore and we accept things we shouldn't.