• Debugging an IIS hosted web app

    Some at my work had been wondering how to enter into debugging (Via the f5 key) in visual studio .Net when your project is hosted in IIS. Since i had been working with WPF Xbap application, i was already familiar with how they did those and figured this would be much the same, and it was... marginally different. :)

     

    First set your project as the startup project, then make sure your Default.aspx or Login.aspx is set as the start page. Right click your web project and click properties.

     

    image002.jpg

    Select URL debug mode, Hit “APPLY” (or you won’t be able to type in the start URL field), then enter the URL that points to your local IIS hosted application.

     

    When I Hit f5 at this point, I had received this error: “Error while trying to run project: unable to start debugging on the web server. The web server has been locked down and is blocking the DEBUG verb, which is required to enable debugging. Click help for more information.”

    image004.jpg

     

    So I searched and found this link about the error:

    http://www.velocityreviews.com/forums/t91432-the-web-serve-has-been-locked-down-and-is-blocking-the-debug-verb.html

     

    The solution was as follows:

    add DEBUG to allowed verbs of the URLScan.ini file which is located at:

    C:\WINDOWS\system32\inetsrv\urlscan

    (see below)

     

    image006.jpg

     

    Do an IISRESET (Type iisreset in a command prompt window)

     

    I Tried f5 again at this point and I received this error: “Error while trying to run project: Unable to start debugging on the web server. You do not have permission to debug the application. The URL for this project is in the Internet zone. Click help for more information.”

    image008.jpg

     

    I web searched for it and found this blog article about the error:

    http://geekswithblogs.net/ranganh/archive/2005/12/30/64446.aspx

     

    it said to modify my internet security setting like this: (start, control panel, internet options, security tab, click internet zone, click custom settings)

    change it from automatic logon only in intranet zone to “Automatic logon with current user name and password” ( I imagine you also could use prompt just fine?)

    image010.jpg

     

    Hit f5 in vs and it should work now.

    Full story

    Comments (0)

  • 1990 300zx NA AT 199k mi 3900obo

    CLICK for PICS

    rebuilt transmission with less than 100 miles (under 3 year warranty with certified transmission)
    new injector wiring, 1 new injector (new njk sparkplugs with that)

    oil change every 3000miles with filter since 178k by me (mobil high mileage, fram filter)
    great motor, dyno'd at 174rwhp (so i didn't bother to test compression beacuse i think it's good)
    new timing belt at 180k
    new water pump at 180k
    new alternator at 180k
    new 1 piece z1 drive shaft
    SPL adjustable upper arms
    SPL adjustable tension rods
    3 great tires (bought at ~180k)
    CDplayer (sirius/hd radio)
    500watt amp (not hooked up)
    2 10inch subs (not hooked up)
    viper aftermarket alarm and remote start
    power windows great
    heated mirrors great
    climate control works (see below about A/C)


    the bad:
    third brake light doesn't work, electrical problem
    left t-top leaks ONLY in a very heavy rain, and it's only a tiny random drip, usually when you stop at a light.
    e-brake doesn't work
    spedometer and temp gauge are broke (odometer works, needs gauges)
    front lower crossmember needs replaced (previous owner made a custom lower arm adjustable camber mod to it... bad news)
    one horrible tire (see above)
    air conditioning has no coolant (may have a leak, needs tested)
    unsteady idle (hurst says it might possibly be idle control motor)
    1 weak injector as per hurst when the other injector was replaced (@198.5k)
    cracked right steering boot on tie rod( i have part, just never put it on )
    antenna won't go down (wind bent, motor dead?)
    various nips and chips in paint and clear coat is peeled in places on rear quarters.
    carpet is curled in hatch area

    NOT save to drive until lower crossmember is fixed and spedo is fixed, otherwise it's good to go. for those 2 things i Estimate (approx 1000 in parts & labor if you find used parts)

    I love this car and will miss it greatly but i just bought an 06 enthusiast 350 so it's time to move on and make room in the garage.

    Great parts car or a fixer-upper
    this is a full disclosure, please come see

    [913] 219_1433 (james)
    $3900 OBO (cost of my new injector and rebuilt transmission)

    Full story

    Comments (0)

  • Solving Problems not Symptoms

    I was reading up on RCA http://en.wikipedia.org/wiki/Root_cause_analysis and was thinking back to my days at the helpdesk. The organization i was in was infamous (at least at the helpdesk) for putting bandaids on symptoms and not realizing root causes.

    "This workaround solves the problem, why should we escalate this to the developers? We can just do this instead" (over and over and over infinitely).

    Problem was, with each incremental patch there were new symptoms of problems and an ever increasing volume of calls.

    When you're seeing a problem, don't just take it at face value.

    for example: If suzie keeps coming late to the stand up meeting and refusing to pay her 1 dollar for being late because she swears her clock is more correct than the teams'... take the time to find out why, let her know you want to solve the problem but don't make it sound like it's "HER problem".

    "susie, the team agreed to meet at 9am and we've been noticing that you're continually missing that time. Is there something as a team we can do to resolve this problem? Could we maybe move it back 15minutes? Or is it even about the standups? is something else going on?"

    As team members we all have EQUAL stake in the project and equal responsibility... granted some of us can't handle that and may opt to remove ourselves from the team. 

     

     

     

    Full story

    Comments (0)

  • back seat driving

    after reading the following blog: http://blogs.techrepublic.com.com/10things/?p=262 at work, we were all trying to pin different stereotypes to our teammates and i decided to pin one on myself and that was the evangelist.

    Now, I do already realize these traits in myself and have been working on keeping to myself with my flamboyance for evangelizing but still put in words from my experiences and readings.

    Coupled with focusing more on my own tasks and projects and less on other people, One thing that i feel is helping me right now is asking questions instead of telling solutions....

    Try asking questions to that get the person to realize what it is they're doing wrong or at least notice that what they're doing isn't working and they'll start looking for answers to that problem.

    One thing that might be an easy example is "every time i change something in my code it breaks the application and i have to go into the debugger to find the problem".  So i might ask something like "how many responsibilities does that object you're working on have?" "What is the code supposed to be doing?" "does the code communicate what it's doing really well?". Some of these lines of questions could bring you around to an opportunity to tell them about TDD(test driven design), simple desing, single responsibility principle (SRP).

    Something that might be a little more complex is an issue that can be 'more easily' blamed on someone else. For example: The customer keeps changing their requirements for this functionality. "Did you work from a use case?" "Did you work from a requirements document?" "Did the customer specify a test case for the functionality?". Try to bring the talk around in such a way that they're asking for solutions like User Stories, face to face collaboration with the customer, moving changes to the product backlog, letting the customer know that their changed request will cut into the velocity of the team's current work.

    Full story

    Comments (0)

  • YAGNI

    You aren't gonna need it!

    If you constantly find yourself justifying bits of code for "If"s and "When"s that aren't on the user story you're currently coding for and there's no test case really defined for it, then most likely you don't need it!

    I might add you should probably also add "This increment" to the end of that...

    "You aren't gonna need it this increment!"

    So each iteration when coding, don't go writing some crazy abstraction to facilitate some functionality that you may or may not know is on the product backlog (unassigned user stories in xp terms).

    WHY?

    well think about these things:

    The product owner may take that functionality off the product list completely before the next iteration.

    The product owner prioritized the work the way it is and you chose the tasks you had based on the ability to do only those tasks and no more. So if you do other work you take away from the velocity of the currently assigned tasks. Not to mention your own personal velocity.

    You aren't the product owner or the customer, you're a developer. If you want to be product owner and decide what gets created, then apply for that job and when you get it then you can decide!

    Anyhow, Agile is about team heroics not individual heroics... so please just write what you're expected to on the tasks and move on.

    K.I.S.S. (Keep it simple stupid) also applies for most of these things.

    Full story

    Comments (0)

  • Agile estimating

    if you haven't picked it up already, i highly recommend Mike Cohn's Agile estimating and planning

    I'm in the middle of it but i particularly loved the discussion between why to use story points over 'ideal days'. For those of you not familiar with a story point it's an estimation of value in relation to other estimates of value or saying "that's about a 5" to a middle sized story or "that's a 1" to the smallest story you have then relating all other stories to that one based on their difficulty,risk, and or size.

    Mike's example was using dogs but i'll use vehicles because i'm a car buff. Say you have the following 'car points' you can assign to cars based on their size, what would you assign these cars:

    1. 2007 Mitsubishi Eclipse
    2. 1994 300zx Twin Turbo
    3. 2006 Hummer H2
    4. Mack Truck
    5. 1971 Pontiac LeMans Convertible
    6. 2001 Honda Shadow 750
    7. 2007 Mini Cooper Turbo
    8. School Bus

    ok, think about those and how you'd order them based on "relative size" to one another.

     

    -- here's my list

    1 - 2001 Honda Shadow 750
    3 - 2007 Mini Cooper Turbo
    5 - 2007 Mitsubishi Eclipse
    6 - 1994 300zx Twin Turbo
    8 -1971 Pontiac LeMans Convertible
    15 - Hummer H2
    20 - School Bus
    40 - Mack Truck

    I figured a mini cooper is about 3x bigger than a motorcycle, an eclipse is a little less than twice as big as a mini, so on... and i assumed the mack truck had a trailer and therefore was twice as big as a school bus (full size not the short-bus that i rode to school  :)  )

    Anyhow, the benefits of estimating based on relative size (according to mike) are that

    1. Story points help drive cross-functional behavior (people don't say things like "well my part will take x ideal days, what about your part" and then add them)

    2.  Story point estimates do not decay (as i get better at something my story points still mean the same thing in relation to other estimated stories)

    3.  Story points are a pure measure of size, it's easier to estimate by comparing other things than a fixed time

    4.  Estimating in story points is typically faster (people don't go thinking about things like individual tasks that make up the story etc)

    5.  My ideal days are not your ideal days (i run the mile in 7minutes, my healthy athletic pal runs it in 5... we're going to estimate the same task with different ideal days)

    Full story

    Comments (0)

  • Agile code documentation

    Time was ticking down on an important project and management was breathing down engineering's neck. Engineering had been given 'one last' opportunity to decide it's fate by choosing a direction and running the ball. They chose a path and started executing it, and amazingly, things started to move quickly.

    The following morning, the daily stand up was turned into a three-ring-circus of chickens and pigs from other teams to find out what the hub-ub was about. Engineering was asked for an 'overall' progress report instead of the standard round-robin 3 questions (what i did, what i am doing, what it impeding me).

    After a synopsis by one of the senior engineers, marketing popped in with a comment, "How are you documenting this process?". To which, John responded almost sarcastically because he knew there was no damn time to document anything, "Our unit tests will be the documentation."

    Astonishingly, another high level chicken chimed in stating, "Yes, but there should be additional explanation on the code."

    One of the primary lessons of xp is that code be simple and the tests be the form of documentation for the system. Obviously, in a rapidly changing application/system there is a lot of churn on the documentation and updating said documentation can take up more time than actual programming tasks.

    If everyone writes code that communicates its intent every well, occasionally sticks ///<Summary> tags on their public methods and properties where there is least likely to be change, and writes unit tests all components/projects then documentation should not be much of an issue!

    Full story

    Comments (0)

  • Unit Testable VS 2005 Projects and Components with NUnit

    Several of the books I’ve read lately have been mentioning different ways to apply test driven development to your code but they really don’t talk about how to set that up in the IDE. I’m a vs2005/vs2008 user so I thought I’d describe how I set that up with respects to using NUnit. Eventually I’ll cover the VSTS unit testing (once I’ve actually used it on rosario) and the vs2008 testing (good idea Brent).

     

    I’m going to quote from Robert Martin’s book: “Agile principles, patterns, and practices in C#”.

     

    Let’s say we did a whiteboarding session and came up with the following UML:

    image002.jpg

     

    If we sat down and decided to write a unit test specifically for Payroll we’re going to have some serious problems because we can’t do so without also writing Employee Database, Checkwriter, or Employee.

     

    Basically, in bob's book he says you'll eventually come up with a design like this that would fix those dependencies to allow you to unit test:

    image004.jpg

     

     you can now build a test like this:

        [TestFixture]

        public class PayrollUnitTest

        {

            [Test]

            public void TestPayroll()

            {

                IEmployeeDatabase db = new MockEmployeeDatabase();

                ICheckWriter writer = new MockCheckWriter();

                Payroll payRoll=new Payroll(db,writer);

                payRoll.PayEmployees();

                Assert.IsTrue(

                    (writer as MockCheckWriter)

                        .ChecksWereWrittenCorrectly());

                Assert.IsTrue(

                    (db as MockEmployeeDatabase)

                        .PaymentsWerePostedCorrectly());

     

            }

     

        }

    Of course, it doesn’t build because we don’t have the supporting objects or method stubs, so let’s do that…(note I’m using interface references so I can auto stub the interface methods and then ‘as’ casting them so I can stub the mock methods)

     

    So once i stubbed things in and added my objects i get the following project setup. I’ll leave the thinking of implementation up to you.

     

    image006.jpg

     

    download the source

     

    Full story

    Comments (0)

  • Two kinds of "agile" organizations

    1. Those that are working to be agile but recognize problems in their development that don't fit the manifesto and attack those problems, usually implementing best practices from XP, Scrum, Crystal Clear, or the resources available at www.agilealliance.com
    2. Those that want to be agile so they declare that they are agile and tout the buzzword around, but for the most part continue to 'do business as usual' under some type of waterfall method.

     

    note: there is no true agile team that does everything perfectly, because agile is always about recognizing problems and attending to them. The biggest problem i've faced in any organization is their inability to recognize a problem as something that they should do anything about.

     

    So, how do i know if i've found a team that is #1 on this list?

     

    1. They have an XP coach, scrummaster, or someone who is an expert on and facilitates agile practices.
    2. The team is allowed to recognize problems and bring them up to the group through having daily scrum/standup meetings (use the term standup meeting or scrum meeting… or timeboxed meeting) where people say only 3 things “what they are doing” “what they did yesterday” “what is blocking their path”
    3. The development team HAS a customer on it (or a good proxy of a customer – good means: Not marketing, not ceo, not project manager, but someone close to the real users of the product)
    4. Everyone on the team is a “developer”, there is no ‘testers’, “architects”, “QA as their own roles. Everyone does everything, it’s ‘crossfunctional’

    how do i know if they're #2?

    1. they'll tell you they're agile
    2. they have an architect, probably draws diagrams but never actually codes
    3. they work from designs instead of from communication directly with the customer. (designs are 3 times removed from the words of the customer)
    4. the developers are always getting hit with a fire drill of some sort "Oh we have a demo in 3 days that needs primary attention"
    5. the source code doesn't clearly communicate the intent of the software so it's supplimented with pages and pages of documentation.
    6. they don't have daily (or at least bi-daily) standup meetings
    7. they don't have unit tests
    8. they don't have acceptance tests
    9. they dont' automate ANY tests
    10. they work from a set scope (this means they have to forsake quality to meet time commitments often unless their PM is clairvoyant)

    Full story

    Comments (0)

  • Agile Statement of work?

    There's no doubt the customer drives development, but how they drive development is up to the chickens (http://www.implementingscrum.com/ for what a chicken is).

    Edgar, a PMP project manager with a huge set of credentials and years experience was showing John the statement of work for their current project. He said, "John i made sure that certain parts of it were vague so that we'd have leeway in what we could make so we can meet the schedule".

    Is it really the policy of PMP professionals to build a statement of work that is so huge but so vague that it can easily be re-interpreted?

    YES

    Why? because the purpose of a statement of work in a non-agile environment is to interpret the customer's need into something the Project manager is positive he can build within that timebox... ie something he's already seen built before. NOT what the customer actually wants, mind you.

    Also, this sets up the gunsights on the customer for the blame game when the product is delivered and doesn't meet the customer's expectations BUT matches the statement of work!

    How many times has a customer said "Well you built what i asked for, but not what i wanted"  ?

    By definition, i don't think a statement of work can be written to suit an agile team because it clearly defines scope (or it should anyhow, though do they ever accurately do so in software?).

    Instead of a SoW, try making contracts with the customer that define HOW the team, including the customer's team member, will work together to bring about the software in an iterative manner.

    If you absolutely must have a statement of work(government contracts?), do the XP planning game up front and figure out the high level user stories, have the customer prioritize them, have the engineers estimate them, build an iteration schedule and make that the statement of work.

    Full story

    Comments (0)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. Next page