• setting HttpRuntime.AppDomainAppVirtualPath

    So i was trying to create an instance of a page class that inherits from some vendor code and has a bunch of dependencies in the constructor. Normally i would apply the pattern out of Michael Feather's book called Parameterize Constructor (basically add the dependency as a parameter and then mock it).

    However, this was vendor code so i have no choice really and i really wasn't feeling interested in making a whole new chain of inheritance and implementation of interfaces just to seperate the dependencies so i started digging...

    anyhow, the gist of it all was that i had a private static member that i wanted to put a value into, but it's on a sealed class and it's private and static so i can't override it and i can't inherit from it.

    After reading a little more up on reflection (and examining HttpRuntime in the reflector to figure out the member names) i eventually got something like this put together:

                            [SetUp]

                            public void Setup()

                            {

                                        HttpRuntime theRuntimeInstance = GetTheRuntimeInstance();

                                        SetHttpRuntimePath(theRuntimeInstance, @"c:\dev\ProjectFolder\");

                            }

     

                            private static HttpRuntime GetTheRuntimeInstance()

                            {

                                        Type HttpRuntimeType = typeof (HttpRuntime);

                                        BindingFlags bindFlags = BindingFlags.NonPublic | BindingFlags.GetField | BindingFlags.Static;

                                        return HttpRuntimeType.InvokeMember(

                                                    "_theRuntime", bindFlags,

                                                    null, null, null

                                                    ) as HttpRuntime;

                            }

     

                            private static void SetHttpRuntimePath(HttpRuntime theRuntimeInstance, string absolutePath)

                            {

                                        Type HttpRuntimeType = typeof (HttpRuntime);

                                        BindingFlags bindFlags = BindingFlags.NonPublic | BindingFlags.SetField | BindingFlags.Instance;

                                        HttpRuntimeType.InvokeMember("_appDomainAppPath", bindFlags

                                                                     , null, theRuntimeInstance, new object[] {absolutePath});

                                        HttpRuntimeType.InvokeMember("_appDomainAppVPath", bindFlags

                                                                     , null, theRuntimeInstance, new object[] {absolutePath});

                            }

    basically, the first method retrieves the singleton instance of the HttpRuntime

    then the second method goes and inserts private member values into 2 fields the app domain paths.

    With a reflective language, it's not always necissary to break dependencies... although mutating private state like this could probably get you into a lot of 'trouble' and it's certainly not clean to look at!

    Full story

    Comments (0)

  • Scrum: Surgical team

    Mythical Man Month is a great book of essays and I was reading this blog that talks about how the surgical team is a little bit strange in the present day because most of these jobs are automated. I thought i'd break it down to how i've actually seen it work or envision it to work in a scrum team. Keep in mind, i feel these are more of "roles" than positions. Some people might fill multiple roles... generally i've seen most people do fill multiple roles on these types of cross functional teams.

    • The copilot (hopefully an equal in programming ability to the surgeon so they can trade off back and forth pair programming, but usually there is one who is more experienced and driven)
    • The administrator (Scrum master role : usually this is a QA guy for some reason, maybe because their knack for getting things done with no authority)
    • The editor (Sr Business analyst and Jr Business Analyst, or the customer team. )
    • Two secretaries (admin assistants who bring you food for late night deployments, arrange parties, keep supplies fresh and conference rooms available. Two seems ridiculous for 1 team though)
    • The program clerk (svn does most of this, but it's great to have a jr business analyst to document the tricky bits of the specification, if for not other reason than to make an instruction manual for someone who can't read test code)
    • The toolsmith (a build master or general hackery guy. "Mr Fix-it". I usually recognize this guy by his huge desire to 'get into things and rebuild them')
    • The tester (QA guy or the business owner)
    • The language lawyer (For example a DBA you run to for TSQL queries, or that guru c# developer in the cube next to you)

    Full story

    Comments (0)

  • Enterprise architecture, cross cutting concerns and agility.

     

    I’ve been moderately unconcerned with architecture for some time because of my ‘agile’ principles. Why? Architecture is the result of good engineering practices at the team level. However, who keeps their eyes on the road at an enterprise level?

     

    What is architecture? To me.

     

    Did you ever hear the story about the girl that goes into the doctor and pokes her elbow and says “Doctor it hurts when I do this” and the doctor says “Well don’t do that then”. This is basically what architecture is all about, for me. It’s about seeing a painful place in the structuring of all of your applications and infrastructure and making an effort to improve that.

                For example, if I have to change 3 classes for 1 software update that I have to do pretty frequently… then I probably could make some architectural refactoring to improve that design so that I only have to make one update.

                If there is an issue with a specific vended DBMS that causes many support calls then I might change my architecture to move over to a different DBMS.

     

    How does architecture happen at the team level?

                Generally speaking, you start small by choosing what programming language your team members could do their work in the best. You might choose a specific hardware platform. You might choose some frameworks that have a core set of functionality that could save you time. You might choose a vended application that does the work for you (and maybe you’ll modify that).

                Once you have the tools in place, you’ll start writing code. If you’re doing TDD, the design will evolve from YAGNI and DRY one test at a time (or red,green, refactor). If you’re not doing TDD, then you’ll probably do some analysis and design up front (use case, uml class modeling, crc cards, or something like that to get an idea of what structures you’ll make in your code).

     

    So now, the problem.

                You’ve got your great application architecture and it’s utilizing your Core software (or and ESB / SOA between that and you).  Let’s say you’re the first application to display enterprise account information. The ESB’s job is to just provide you data and then you provide the presentation, right? So you consider things like commas in large numbers as presentation and code it into the UI, you consider authentication part of the presentation and code that into the UI, you consider caching as part of the presentation and put that into the UI.

                Now some other team goes to create a new application that presents account information. They only see what’s in the ESB so they write all of those Cross cutting concerns AGAIN.

     

    This is where the need for an enterprise architect should come in. This architect needs to be able to see that things are being repeated and to align business units and technology people into a common goal of solving this rework problem. Things like AOP can be used in java and c# to be able to wrap business entities and use webservices to provide the cross cutting concern (logging, auth, formatting, etc).

     

    I wonder if this is really such an issue if you've implemented scrum of scrums in your organization since the highest level scrum team would be an enterprise integration team?

     

    Full story

    Comments (0)

  • If chickens had balls, i'd kick them.

    The great part about being a chicken for a scrum team, is that you don't have to commit to anything. It's pretty cool... you can get a phone call from someone on the scrum team and say "yea, well your lack of planning doesn't constitute my emergency, so what are you going to do for me?"

    "Well, i'm going to kick you right in the balls! How's that sound?"

    Ok, but really... how do we collaborate with chickens productively? Because chickens need to know ahead of time (sometimes ridiculously long lead times) to do things for you.

    Like: IT server requests, certificate requests, network changes, legal approval, marketing approval.

    So you may be asking why aren't these people ON the team?

    Good question... why aren't they at your organization?

    We frankly can't find enough for them to do to keep them busy 24/7 so we think we can do without them on the team.

    I have been trying to get them into sprint planning meetings so we can get their commitment on things before we commit to things that require them (if we know ahead of time that we're going to need them)

    Oh crap, another catch 22.

    Kinda like how you shouldn't refactor without unit tests but you can't put unit tests in your existing code without refactoring...

    Well anyhow...

    I don't hate chickens... they can just be a pain to work with some times. We just have to strike a happy balance of planning with chickens so that can participate with us.

    Full story

    Comments (0)

  • Measuring Undoneness (or the amount of work NOT done) in scrum

     

    We all know (or i should hope to god that we all know) the ultimate “Done” is: Released, in production, and delivering business value to the customer.

     

    Obviously, this isn’t always achievable so in scrum we create a mutually agreed “Definition of Done” between the team and the customer. This definition might be something like this:

     

    User Acceptance tested

    Installed on a QA environment

    Documentation Completed

    Coded to specifications

    Coded to standards

    Peer code reviewed

     

    And so on (think about your own organization here)

     

    Now, what I’d like to point out here is the variance between your definition of done and when you’re REALLY done (installed into a production environment and delivering value)

     

    For example, what integration has to be done from QA to production? Is it a manual procedure? How many man hours will it take? What if you find something during that time that has to change? (That is risk because it can’t be estimated).

     

    At one organization I am familiar with they merely have to copy the executables over into an IDENTICAL production environment. That amount of effort is very low and probably not prone to much risk (but there is some so we should measure it)

     

    Let’s see how we can do something like this with an example user story and tasks.

     

    Let’s say I have this user story:

    Retail banking customer can see their savings account balance so they can decide if they have enough money to buy a new boat.

     

    Ok, now let’s task that out to our “Definition of Done”

    8 hours User Acceptance tested

    2 hours Installed on a QA environment

    3 hours Documentation Completed

    12 hours Coded to specifications

    3 hours refactored to standards

    2 Peer code reviewed

     

    OK, now let’s task out how much more it would take to put this story into PRODUCTION:

    2 hours Create installer

    3 hours create change control package

    1 hours create web.config file for production

    1 hours test web.config file for production

    1 hour install the application

    2 hours validate the application in the production environment (re-run regression UAT scripts)

     

    So, that’s 10 hours of things that we are not going to do with this user story based on our ‘definition of done’ but they ARE contributing to our technical debt or our RISK.

     

    So, let’s create a user story that represents this, give it a ‘size’ and put it on our backlog!

     

     

     

     

     

     

    Full story

    Comments (0)

  • Scrum is not a silver bullet.

    So it's hard not to explain the values of scrum (process improvement, project management framework) without sounding like a snake oil salesman to management. It happens all too often that the word scrum or agile gets thrown around with little, no, or misunderstood meaning.

    One interesting misinterpretation I had used against me when arguing that the customer was taking advantage of scope and violating the simple principles of scrum's sprint framework by asking the team to take more than it had committed to. They said that I needed to be more "Agile".

    What they had interpreted "Agile" as was that I needed to do more "What the customer wants".

    I found an interesting article on some scrum misinterpretations (by no means a complete list, but some less common ones than i've seen) 

    Now, i don't totally agree with any of these things, but what WAS interesting and I do fully agree with is this statement:

    Scrum, when done properly, is wonderful.  It creates a way to learn and move forward.  When it is thought to be an answer beyond the agile project management method that it is, it can be counter-productive.  Scrum should be used appropriately and by people who understand why it works. 

    This is a pretty powerful and true statement. I've seen so many misinterpretations... like "War rooming" being used to pressure developers into hurrying up (instead of for it's collaborative benefits). Or scrum meetings being used for control-freak directors (or managers or project managers) to get all of their information in one 15minute shot to the arm (instead of a meeting FOR the team members).

    And i'd love to hear what scrum Misinterpretations YOU have faced in your organization :)

    Full story

    Comments (0)

  • Agile: Handling Security with Scrum or XP

    So as with every financial institution, we're particularly concerned about security and faced with MANY tools and processes that are in place regarding security I found myself sitting face to face with one of our consultants and being asked the question "Where does security fit into your framework? your methodology?"

    I found this an interesting question, and I answered "The team should decide" quite proudly.

    Of course, he pressed on, wanting to know my own personal opinion about the subject. To which, everyone knows, I felt 'obligated' to answer.

    Now, I don't really remember how I answered at the time, but I was just pondering it again this evening after a presentation of user stories at our local user group

    So, one possible thing to do, is make negative user stories like this:

    As a hacker i want to steal your user id so i can brute force your password.

    as a hacker i want to find out what version of operating system your server is running so i can exploit vulnerabilities in it.

    as a phisher i want to inject script into your website so i can get your password

    Ok, so that's all dandy, i have negative user stories that i want to "Implement", but how do we know to come up with these?

    Well, let's say you do a code review with a security consultant (or use a tool that scans your code). Everything it finds could be explained to your customer and the risk weighed and a story card generated.

    AND perhaps, having a code review and checking for secure coding practices is part of your Definition of "Done"?

    AND remember the real goal of xp and scrum is knowledge transfer! So the more often each member of the team works with 'secure coding practices' the more they learn and the more they know for next time.

     

    Full story

    Comments (0)

  • Agile Leadership: Accountability

    Chris Leon brings up an interesting point about being a "manager" for self managed teams.

    First of all, it got me to thinking... why do we need managers if our teams are self managed?

    Maybe we don't need them at all, maybe we just need Shepherds or Leaders. Ken Schwaber likes to call them 'prick' (or scrummaster)

    Kent Beck (Extreme Programming) calls it an agile coach

    Allistair Cockburn calls it "Coordinator", effectively a very lightweight project manager who who helps the team adhere to the principles and practices of crystal.

    Secondly, what do all of these roles have in common:

    They all protect the team from outside influences/interruptions, they guide the team as subject matter expert on agile practices and principles, they provide some of the same things a project manager would to the organizations they work in, they work for the team (not vice versa) by removing roadblocks, they act as counselor and teacher more than commander in chief.

    Lastly, how can we track such things? How do we introspect to become better leaders of self managed teams?

    Maybe we should be asking their teams.

     

    Full story

    Comments (0)

  • Jerry talks innovation

    http://certellus.blogspot.com/2008/07/technical-installment-advise-week-4345.html

     

    Full story

    Comments (0)

  • XNA Game Studio 3.0 Release

    XNA game studio 3.0 came out... and finally... it can be used with regular visual studio instead of only the express edition.

    If you want to learn game programming in a fairly easy environment, XNA is pretty cool for that (albeit i haven't touched it since 1.0 beta).

    I'll be checking it out soon and maybe let you know more!

    Full story

    Comments (0)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. Next page