Jonathan Crossland's Talkware

When to utilize SCRUM:

• When requirements are sketchy and poorly gathered
• When there are new requirements
• When existing functionality needs to change
• When you are fire-fighting bugs, issues and points of failure
• When you need to quickly get back into good grace with the client after tons of issues
• During the very initial investigations of the project, research and understanding user stories
• When Use Cases are not being met properly and you need to get things on track functionally
• When new members join a team, or an increase in communication is required.
• When the product owner needs to balance a backlog
• When there is a lack of responsibility and accountability

When NOT to utilize SCRUM (prefer a more Agile Methodology)

• Gathering requirements
• Designing the system functionally
• Designing the system architecturally
• Core Development phases
• Development phases which require design
• Phases dedicated to Refactoring
• Phases dedicated to Testing
• When roles and responsibilities are defined properly
• When requirements are consistent and relatively static
• When management and interested parties are not committed to it

SCRUM is not a silver bullet and no team, in my opinion can afford to put all their eggs or life-cycle phases into one basket.

Updated:
Scrum or being agile is not something that can solve your problems. It is rather the the team, leadership and real productive processes that count more than anything. A person unskilled in leadership and who does not have the complete 'vision' will fail in whatever processes are in place. And those that are good at leadership and management, were agile and good at it, before any methodology was created.

I think most importantly, a leader must care, be focused, be open minded and must seem to 'see into the future', as his intuition will show through.

Tags: scrum, methodology, agile

Agile Methods are a people-centric way of running projects where increasingly teams are accepting that it has tremendous value. However there is more weight put on the code for an Agile Method based project, as with more deployments, milestones and iterations, there is either a need for more refactoring over time, or a more future-proof design is needed. However both refactoring tools and greater predictive powers on the future of the code are both valuable tools.

However, if the software being crafted is not of an equally high and maintainable standard, the project can also fail at being more agile, (just like a people-centric approach can fail with the wrong set of people, irrelevant or bad design can affect the iterations and deadlines).

The software design should also be crafted in an Agile way, to support the Agile Method governing the people. However, being more agile in code does bring in some side affects.

• An increase in software abstraction
• An increase in configuration and meta data
• An increased requirement for intelligent design
• A more controlled, standardized, patterned and convention based development environment

Currently though, I see a gap between the Agile Method and the code written within the project. ie. the relationship between the agile software and the Agile Method.

There are many reasons why teams using Agile Methods could fail and I include design and coding into that list.

I believe that:

If being more agile is being more 'adaptive' (rather than predictive), then being more agile in code, needs the counter-weight, which is 'predictive', rather than 'adaptive'. I believe code should be more predictive of future changes, the more adaptive the business becomes. The balance of the two concerns is where you will find a good software system with happy clients. It is all the balance.

Tags: agile methods, methodology, development

The Next Generation of software needs a better, cross platform software abstraction layer.

The Software Abstraction Layer needs to be a small, yet effective and efficient set of utilities and types, that make the base activities in software seamless and effortless.

I cannot dictate what exactly should be catered for in the layer, but there are some problems in our software world that never seems to go away. Some bugs that always need to be dealt with, and complexities that are pointlessly time consuming.

Some of these like features should be perfectly dealt with, bug free, within our platforms, like culture, regional formats and time zones which are still not implemented as well as it could be in the most widely used platforms. .NET took years to get to a usable level. There are several libraries for Dates, all working differently, different benefits, different bugs. But there are other features, infrastructure features that are universal problems, yet universally different on each library and platform you use.

 

But more than that, the "levels of abstraction" are entirely different, all the libraries and platforms are being created with profit and business in mind. They are not designed appropriately enough to be a bedrock for all software. They (like .NET and Java), improve with each year, but they are too different, yet too similar beasts. They all have flaws and goodness, but they are not the same, nor compatible, nor solid.
If you take berkley sockets, or other open source projects where the aim is 'software improvement', not money, things begin to change, but not entirely, as there is no standard to work from either.

 

The Next Generation of software needs a HAL or a Software Abstraction Layer. Except this layer should be a collaboration from many parties, and it should sit above all operating systems, for all platforms. This layer should have programmatic certainties, like guaranteed Dates, across platforms, internet, databases (insert your abilities here). Think of it as a merging of the core data types and functions of .NET and java and the like, into a definite agreed interface that sits on all platforms.

We need a common infrastructure to achieve the next ge neration of software, else we are just widening the gap between platform and system, making users more confused, developers more diverse and many irrelevant to other technologies. 

I want to see Microsoft, IBM, Apple and other important players join up and create "the software layer", that will exist, just below java, just below .NET, and is the same across the platforms. A layer that will disappear like tcp/ip into the layers of inner workings, away from most developers. The benefits of this are enormous.

let's face it, .NET, nor Java are perfect, and how far can each go? How large can the libraries get? until you need another layer on top? I think we need to get the lessons learnt from java and .net into a universal software abstraction layer, that raises java and .net higher up the food chain.

Tags:

&

On the concept of contracts and contracts, I think we need "interface phasing". Having a phased relationship between two parties.
It is imperative that objects and at a higher level, an Application, can change the way they interact by who or what is accessing them.

 

An object should present itself differently to different audiences. Imagine a developer seeing a specific interface, but not a user, or IDE vs developer. Its not role based, because it could be different per application to application communication, although a similar effect can be achieved.

The concept is simple.

I think that coding today suffers from

• Repetitive nature of structural elements: for example: creation of large Object Models, classes, properties, collections and so on.

• Creating Object models with no separation of Context or concerns. I want an object to 'share' code, but for different reasons. Cross-Cutting. Yes, I can create a new object and share code, but that's not always the answer. Imagine two object models, where one is a Facade of the first. I want to simply map the one to the other, not create the entire structure for it again.

• Different ways of extending components. Different ways of creating add-ins, Custom B2B, Adaptors, Bridge patterns etc. It can all be made easier, if we used a "Global extension object system"

• The 'under the hood' 'abstractions, keep changing - not for the better or necessarily for the worse, but for no distinct benefit.

• Contractinitis - Nothing works unless its all explicit. In .NET, can't call the web service with your Person Object, cause its not the same namespace etc.

 

Create automatic and dynamic proxy layers based on metadata and intention of communication. The code is then 'assembled' and made ready for the communication. The code is assembled from existing non contextual code that can fit into a common proxy container and interact.

On a simple level, imagine, you create SOA like methods, stateless and they are formulated by the runtime into a new object that looks like the one required.

This is not the complete answer, but we really need to get to 'smarter relationships' rather than contracts.

See Lack of MetaData on code and .NET Framework libraries

Read Evolution, Architecture, and Metamorphosis - A great piece of work.

 

Tags:

Our software contract world is the accepted norm, and of course we have come a long way with the philosophy as its been the corner stone of our development languages and platforms for how long.
However, other concepts have also existed. In the seemingly archaic world of top down programming, there were no interface or object-oriented contracts. Instead a form of duck-typing and vtable calls ruled the day or even worse pointers and addresses.
Today the concepts of interface and implementation etc are sometimes lost on the new generation of developers, as its so seamless today.
However, I think that if you look at the real world, communication is lossy, and not defined by the same kind of rules.

In the real world we kind of just make sure there is someone around, or get the person focused on us, then we talk. The receiver understands or does not understand, or does not listen, or hears and acts on all that is said. In the real world, not every communication has "roger", "over and out". There are obvious benefits to having it sometimes, but a real pain in other situations.

The interaction of software frameworks is a real candidate for a more lossy communication, or a Communication Agent, put in software terms. The ability to translate messages from "intention to result" is imperative.

When a call is made to string GetUserName() or string getNameOfUser, the intention is the same, but in our current forms of software architecture, a human would have to use a design pattern, Adaptor, Bridge or whichever suited to accomplish it, when clearly, to our human eyes, the function could well be identical but for name.

A new kind of Interface Definition language is needed to declare intentions of interfaces, and allow a mapping agent to successfully arbitrate a result.

Tags:

When one reads of Frameworks, you cant help from getting the impression that its a large beast of a reusable thing, that then gets reused again and again in the domain the framework 'solves'. You can't be criticized for believing that frameworks are hard to build and harder to grow and maintain. And you would be absolutely correct in thinking that vast amounts of developers cringe at yet another framework to learn. All frameworks are different. They have patterns, but are ultimately different and sometimes extremely hard to learn. All well written frameworks would be beneficial, if it was used.

But look at what we have to work with. We build frameworks using objects. We specify frameworks in classes and modules, with interfaces and contracts. All of this is far too low a level for the future of the Software Framework.

A Framework must be built with a higher level language. A framework must have the ability to see itself as a structure for components and a communications platform for other frameworks. This is hard to do, thus not done yet. I like the Business Component Factory. A great book, written a decade or more ago.

I think that a Framework must have connections:

• to other frameworks
• to components

In our object-oriented world we have interfaces that are implemented by an object, but usually only one object (or by composition), at the surface implements that interface. A framework needs more than that. A framework needs an interface that can be declared and implemented across objects and traditional boundaries as well.

One possible form of connection specification is XML, or a DSL that defines and builds the Framework's connections.

Tags:

I was recently asked about what I thought about unit tests and coverage.

Due to each language and framework having unique designs, what would the lower percentage be for testing you .NET Framework code?

I have done some tests, and checked through 49 Enterprise, in-production, Assemblies and 12 personal project assemblies of various sizes. Code coverage has been pushed to the highest, before major resistence sets in.

Based on my tests and observations, it seems around 85% coverage is where you begin to see a large amount of code coverage dependency resistence.

What is code coverage dependency resistence? (is there another terms for this, that has slipped me by?)

When you find writing certain tests, testing certain interfaces etc, are more on the side of the framework, than your code.
When a set of interfaces, should already have framework tests, or tests from your other dependencies.

Each platform is different, but for .NET you should be looking to write between 70-90% code coverage for good results, with 85% being the sweet spot.

Tags:

Since we can target our code to a specific compiler and target the platform of our choice, I thought it would be fun to see what sort of differences in speed, it would bring up.

I did two tests. First I looped through integer values, the columns on the left and then object assignments for the column on the right. For the object assignment, I created a simple class with a string property, created the class and set the property in the loop. Interestingly there were some differences.

The object assignment is obviously a large percentage of what we do in an object oriented world. Visual Studio 2010 was a lot slower than 2008 all round, but did perform decently for .NET 4.0. However small this simple test is it shows quicker times from 2008, and it shows that 2010 suddenly improves when using .NET 4.0. It took around 25 seconds longer to create the objects targeting the .NET Framework 3.5 using VS 2010, than VS 2008.

The test was done in Debug mode, Vista 64.

integer loop
2.0 2008	3.0 2008	3.5 2008
2.7735668	2.7634976	2.7670054
2.7659806	2.7567702	2.771937
2.7700194	2.7612681	2.7782053
2.7697211	2.7606385	2.7811199
2.7750242	2.7747622	2.7802291
13.8543121	13.8169366	13.8784967
2.0 2010	3.0 2010	3.5 2010	4.0 2010
2.7465096	2.7569809	2.7655086	2.734276
2.7577021	2.7531411	2.7583006	2.753255
2.7505392	2.7429336	2.7568989	2.753271
2.741854	2.7503117	2.7655838	2.761961
2.740013	2.7474619	2.7784012	2.759656
13.7366179	13.7508292	13.8246931	13.76242

object creation, string property assignment
2.0 2008	3.0 2008	3.5 2008
15.9305226	15.38386	15.8581671
15.2397368	14.59608	14.7847291
15.1368118	14.7387	14.6265273
14.7425454	15.42782	14.5719368
14.7806622	15.25851	14.9774767
75.8302788	75.40496	74.818837
2.0 2010	3.0 2010	3.5 2010	4.0 2010
20.3244424	20.76454	20.7134072	18.37988
20.2770724	20.61586	20.8497297	18.04806
21.2592798	20.74874	20.856723	18.32123
20.5916017	20.64923	20.897214	18.62922
20.3946783	20.61862	20.7991	18.42922
102.8470746	103.397	104.116174	91.80762

Tags: vs.net 2010, visual studio, performance

The Wizard opened straight away, I clicked next.
After a few popup dialogs, requesting from me things such as Can't find the source control, remove source control binding? and would you like to upgrade the web projects to .NET 4.0?, which I responded yes to all.

The first problem came when the web project tried to bind to IIS, but failed. the wizard asked if I would like to create the virtual folder, I said yes and it failed, since it already existed. Accepting this to be a fair point, I created a new IIS Application, mapped to my project, edited the project file (right click on the project which failed to load) and selected Edit Project file. The edit context menu is a simply but great new useful feature.

I then reloaded the project from the same context menu and it loaded perfectly.

Running the application worked first time. I ran our manual Sanity Test, our automatic unit tests and all passed first time.

In short, upgrading the web app to .NET 4.0 upgraded and ran perfectly well.
but what would it do if I changed the target platform back to 3.5?

I went directly to the project properties and changed the target platform to 3.5, at which point I was informed that a project reload was required.
I then went through all 16 projects in the solution. Some had changed to 3.5, some were still on 4.0. I changed all projects to 2.5, compiled and ran.

The first Error

I got the following error:
"Could not load file or assembly 'xxx' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded."

Oops, I missed one.
I changed the version to 3.5, rebuilt. Still error.

What happened was all the projects hooked up to Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll - refused to change to version 2.*. The project reverted back to version 4.0, and I could not keep it in 3.5.
Eventually, after trying tons of manual attempts to reference alternative versions, rebuild etc, nothing worked and I was done.

Start from the top

I decided to start from scratch, get my backup up and start the wizard from scratch, this time, not upgrading to 4.0 from the get-go.

After repeating the exercise and not moving to .NET 4.0, I discovered that all the UnitTestFramework dependent projects had been forced to version 4.0 and I got the same error as before.

You can view the problem on Microsoft Connect, and as I did, discover that not much of a solve has been written there. (Please leave your feedback on the site)

STOP. It is a shame that one would consider the .NET Unit Testing Framework to be such a small piece of the whole 2010 pie, was the reason I cannot upgrade an Enterprise project. Not good for test first is it?

[Let me just point out that Visual Studio .NET 2010 is in Beta 2, at the time of this post]

Tags: visual studio, vs.net 2010, upgrading, migration

I don't have time for a large introduction to this post, rather I'll jump straight in and tell you about the things that I picked up on.

- The start page, with its now big button, lots of padding approach, seem wasted space, especially on any wide screen monitors. the start page for VS.NET 2008 wasn't anything great, but you had the recent projects, some news and other bits all accessible with one click. A minor thing, but its not a better start page.

- The skinned look. This was a complete waste of time, in my opinion and in fact makes the experience in visual studio worse. With the extra padding, now around all the toolbars (the same width as the splitters), it makes everything seem smaller, and it is. The dragging of the toolbars are much cleaner, smoother than 2008.

I don't like the way the treeview lines and arrows disappear when it has no focus. If it is a setting, I could not find it, but now I cannot at a glance see if a folder has something in it vs one that does. A small point, but means you have to move the mouse and wait for the lines to fade in.

- The code editor now has filtering on what you type in the intelli-sense. Before it simply took you to the correct item in the intelli-sense window, now it removes entries that do not match. This is a massive negative point, as I use the intelli-sense as a browser as well.

- The code editor, firstly which is a major plus, is the selection highlight. Now it is not an inversion of text colour, with blue selection background, it is a translucent colour, which keeps the text colour as it is, untouched. This simple thing is a massive improvement.

- Unfortunately there is a microsecond delay now over 2008 when typing. Each character you type appears that little more slowly, which actually took me a while to get over. It was actually annoying to me. I know I am quite sensitive about it, but I think others will also have picked up on it.

- The skin colour of dark blue with white text on the tabs, now distract me. I always have a black windowed code editor, not the usual white. But now, the toolbar tabs for each file is more visible in my peripheral vision as I type in the editor. This is also distracting.

- The round break point icons in the margin is now that fraction smaller, which I don't like, but can live with.

- Overall, the skin has introduced too much contrast. It is much more stand out as an interface, which is better to look at, but worse to code in.

Why does Visual Basic appear on the root, and c# in 'Other Languages' - on new Project Dialog? Is this a VB editor, then if we are lucky some other languages? I thought .NET was about multi-language.
1. Visual Basic
2. Other Languages
3. Other project Types
4. Test projects

Tags: vs.net 2010

Being an agile developer has meant a lot to me. Over the years, I have tried to get those around me, more agile, more iteratively focused, more quality, result driven and so on, but I fear it is growing askew.

Agile is on the cusp of becoming so customer, service and result focused that quality, reuse, robustness and many other facets are getting less emphasis.

Agility can be a weakness too.

Everything is balance, and I can see two problems amounting.
1. More and more are 'Agile' without actually seriously changing their ways, or actually being agile.
2. Becoming so focused with being Agile, they turn full circle, back to all the clutter there once was.

A micro or macro manager will always have their different approaches, and Agile is not a fix for either. It is a careful balance between the two.

Tags: methodology, production, quality, management

... you know when you have it, or not?

You see it written in code samples: No warranty, please take care if you use in production environment. This is not production code, but what does production code really mean?

Firstly production code can be any code that is in use. But that does not refer anything about quality. Just because software is on the shelf, does not mean its good quality.
Production code must have some sort of quality level.

Amusingly the DSDM pocket book, (Atern) says that "it must be good enough" - which makes me laugh, then cry.

Quality is subjective yes, and quality costs money. So what should production code be?

The following is a list of heuristics for referring to code as production code.

• More than 40% of your application has Unit Tests
• At least 3 or more people have spent time actively seeking bugs, for longer than 30% of the time it took to originally write.
• At least 3 or more people have been actively seeking bugs, in at least 5 different configurations/environments.You have mixed the environment (different server, different database name, altered culture/region, etc).
• Bugs have been solved with SolvingDesign (A lasting solve)
• Code Regression is reduced, practically to a stand-still. A ratio of 50 bugs solved per 1 reintroduced is a good ratio. 5 bugs solved for 1 reintroduced is a terrible ratio.
• Users have used the code for at least 40% of the development time taken, reporting bugs, and the system recompiled and redeployed at 5 times during this period. (preferably at intervals, so input can be recalculated)

Influence that will present itself, and cause you into thinking its production code, before its not.

• Deadline and other pressures
• Reactionary mindset, rather than pre-emptive
• Bad company software creation intelligence (what else can you call it?)
• Human traits, inexperience, carelessness etc

Tags: methodology, production, quality

In order to get a useful, all purpose, all use client-side href link back to root, from anywhere down the web folder structure, and paying attention to IIS6, IIS7, Cassini and other Visual Studio internal web hosting scenarious and of course the odd bug within ASP.NET and your own web site code, I created a handler for ~/.


Here is the html I wanted.

<a href="~/">Some link to root of site</a>

public class RootHandler : IHttpHandler
    {
        #region IHttpHandler Members

        public bool IsReusable
        {
            get { return true; }
        }

        public void ProcessRequest(HttpContext context)
        {
            context.Response.Clear();
            string toUrl = context.Request.ApplicationPath;
            context.Response.Redirect(toUrl);
            context.Response.End();
        }

        #endregion
    }

    <handlers>
      <remove name="root"/>
      <add name="root" verb="*" path="~/" type="Namespace.RootHandler, Assembly"/>   
    </handlers>

Then with a little more code in the ProcessRequest method, you could find the ~/ part of the url, strip it down and modify the url.

        public void ProcessRequest(HttpContext context)
        {
            context.Response.Clear();
            
            string toUrl = context.Request.ApplicationPath + "/";
            string url = context.Request.RawUrl;

            int idx = url.LastIndexOf("~/");

            url = url.Substring(idx + 2);
            
            url = VirtualPathUtility.Combine(toUrl, url);

            context.Response.Redirect(url);
            context.Response.End();
        }

It is only with .NET Framework 3.5, where HttpHandlers have gotten to an acceptable bug free level for use.

Warning: this is a simplistic example for purpose of this post, please be careful in production scenarios.

Tags: code, httphandlers, silly

ASP.NET should have been a plug-in from the start. The IIS Handler, should have been split into (.NET with ASP.NET) and (.NET without ASP.NET). The idea of a config file and a WebConfigurationManager is not and should not have been specific to ASP.NET.

One cannot help but feel that ASP.NET was designed with Web Server Controls as the flagship feature. "Create that 3rd party market for web". No real thought paid into how people actually use the web on simple terms.

What I am writing here, probably resembled the paper David Heinemeier Hansson scribbled on when thinking and designing Ruby on Rails, but I have no intention of mapping features, just stating the obvious.

Get Server returns html
Post Server *saves data and returns html
Querystring may change what code is executed, and change the "context"
Url may require changing, remapping, extension changes etc

Now, to do this in ASP.NET is relatively straight forward?
Yes it is, simple enough to do each thing, but it gets more complicated when you want all these ideas together.

There is also a grey area as to what we should call easy. Yes it's easy to do x, but is it simple and will it remain simple as time goes by.
The minute you start asking some questions, ASP.NET starts to give varying levels of success. What if it was posted from a different server? What if the html had to be static and not dynamic? what if you need to create your own physical files and return those to the browser? What if you did not want an aspx page at all? What if your new Module wants to create the Page (HttpHandler)

Asp.NET is far too cluttered, and muddled. The design from, Web Server to a response, should have been completely extensible and pluggable.

The problems that I have come across, over the last few months (again), have all been relating to ASP.NET not being able to let go. ASP.NET has so many tenuous links to what you write, its everything but impossible to break away.

A framework should always be designed in layers. A framework should not be a large foundational block, written to sit at the bottom only.

if I am not entirely clear, perhaps a few links into oddities will help.
Actionless Form
Scenarios where switching viewstate off like this does not actually work.
and why caching problems like this does not work properly all the time.
Double postback scenarios
The ridiculous IsPostBack code and scenarios
and it does not end. Friendly adaptors, bad html to asp.net naming, lack of rudimentary support for url manipulation, deflected posts and more, makes ASP.NET a framework look like this.

In my humble opinion, on design/framework notions here are some ASP.NET should haves.

• The HttpRuntime and associated server objects should have been better formulated and allow for better involvement. Allow extensibility.
• The runtime should have made Pages (HttpHandler) an optional unit of packaging and code, not the complete target.
• Better fine grained Page type. Split it into more pieces, separating cache, viewstate and more from the design. So we can use at any of the levels of interest.
• HttpHandlers should have been designed as a clear open and extensible list of handlers. The pattern should be more workflow like.
• The compilation process of asp.net syntax and html should have been an exposed set of objects, also extensible. (build providers)
• Expressions should have been designed much better, and give us control of more of the syntax.
• It should have been easy to create an aspx file and not have code behind, and include your own syntactical sugar.
• Asp.NET should have been a plug-in to the .net engine for the web, and not soo tightly coupled.
• Classic ASP should have been a continued 'available' and compatible unit within the framework.
• Should have reduced the gap between Server and Client side code. not server controls writing client code out, but rather a whole new better solution
• ClientID $ in Form and _ in Page? why not allow us to switch it off?
• All that time it took to develop usercontrols and pages and server controls, could have been better spent on using existing syntax and an html object model for controls. It would have been compliant, less error prone and significantly better.

Personally, I cannot wait for the rewrite of ASP.NET. Unfortunately with all the man hours, money and face they have put into ASP.NET - they wont be brave to throw it away. Yes folks you will be stuck with it, and its even going to version 4.

I like the .NET framework as a whole, I love the c# language, but ASP.NET is a beast. Why on earth they built MVC on top, I'll never know. If it was not for Visual Studio supporting ASP.NET, it would be a disaster.

ASP.NET just should not have!

Tags: asp.net, frameworks, rant

Bad, bad, Bad..

I have soo much to write about this topic, I think I will leave it there....

Tags:

I have to build Forms. Web Forms, digital versions of paper forms. You know the kind. You get probably hate filling them in.
Currently there are a few forms, but expectations are, that many, many more forms are to follow. Forms for Edit, Forms with Permissions (part of forms visible to some, editable by others), forms saved as pdf, as html. Each form can expect largely varying workflows. Data from forms to varying database schemas. A complete nightmare to implement generically, but there is a need for a lot of it to sit on top of something familiar and useful across domains and clients.
Some of the goals include:


- easier to maintain, add forms etc, than previous implementations.
- easier to edit and deploy to different sites.
- customizable workflow
- customizable processing.
- Notifications, manual override of process, some manual flow points.

This is kind of like ruby on rails meets Windows Workflow foundation. But alas that wont work out very well, as a combined technology and WCF is overkill in some areas, and might be worth doing on another level. However this is a .NET team, with no WCF experience. Would a quick Activity based object model not suffice?

I have been sitting with this for a few weeks now, and I have 90% of my plan of attack. However, I have started developing already. You guessed it, I have already built a small Framework of my own that will suit this development.
If you have bright ideas, let me know.

Tags: webforms, asp.net, framework, design

Although .NET Reflecton offers a decent look at the Types you build, it is pretty generic in its offering. For example, it does not yet provide us with capabilities to control and secure how Reflection can inspect our Types. If you do not want a Type to be Instantiated via Reflection, or if you would like to restrict certain Types from being visible at all. Further there is no idea for extension or change. One cannot simply plug into Reflection and override behaviour.

High abstractions and higher flexibility

Many more wrappers are needed, at a higher level, which would sit on top of .NET Reflection. For example, architectural dependencies. Agile mechanisms, if code had enough metadata attached, one could alter the code via reflection/refactoring in a much more dynamic way. Consider the following two web service methods in two different companies.

  public class PersonService
    {
        public void AddPerson(string lastname, string firstname, 
            string birthdate)
        {
        }
    }

    public class PersonWebService
    {
        public void AddNew(string firstname, string surname)
        {
        }
    }

You can see that they are completely different contracts. Interface and contract speaking they are like apples and sand. However, to your mapping, calculating, schema, metadata, tagging and understanding brain, its the same thing.

What we need, is to remove ourselves from Contracts to something more like guidelines.

  public class PersonService
    {
        [Operation(Schema:Person, "Add")]
        public void AddPerson([schema(LastName)]string lastname, 
             [schema(FirstName)]string firstname, 
             [schema(DateOfBirth)] string birthdate)
        {
        }
    }

    public class PersonWebService
    {
        [Operation(Schema:Person, "Add")]
        public void AddNew([schema(FirstName)]string firstname, 
             [schema(LastName)]string surname)
        {
        }
    }

Tags: design patterns, frameworks, reflection, metadata

Not sure if there is a Design Pattern relating to this kind of need in another pattern catalogue, but it seemed simple enough to reverse the GOF composite. A class with a collection of leaves, that iterate, recurse its way up to the root. This needs work in terms of combining or actually making a variation on the composite. I think that this is perhaps only a .1 degree of separation.

Problem

You have a list of Items, that may or may not be related. There may be 1 or more trees. You have a bag of unsorted or related objects as a signle array. You need to maintain a complete list of leaves, but also need the relationship/heirarchy to become apparent. You want to express the heirarchy in a Composite Pattern, but it would exclude certain leaves has it has no part in the particular root that the composite gets built on.

Context

You need a collection of leaves, from across the composite tree. You need to have access to the parent and/or recurse to the root.

Types are stripped from its branches.

 

Structure

A class that works with a collection of leaf classes, that each point to it's parent. In effect a composite in reverse. Keep all the leaf objects in a collection and build the heirarchy from the bottom up.




One of the main reasons behind this is multiple paths to a set endpoint. The root becomes the set endpoint where by we can plot a course from a leaf. The Leaf though is where we start from and full knowledge of all leaves should be known at the outset. 

By adding a Parent on the Composite (GoF), you can achieve a similar result, but you will not have a flat list of leaves.

Tags: design patterns, composite, reverse composite

Run VS.NET as Administrator on Vista.

Export your settings using Tools | Import and Export Settings, don't let another windows reinstall take it all away from you.

Get Regionerate
- but make sure you use the "Remove All regions" command, before trying to apply others. It wont replace your existing regions.

Get Studio Tools, for File manager and the tear off editor.

Download Dev /efor - not sure about the name, but it works nicely.

Snippet Editor, useful, for changing the way the existing snippets work, as well as new ones.

Carl J has a large list of add-ins.

Tags:

It is amazing how these sorts of tools divide opinion.
I usually blog about technology, especially framework oriented things, but I have been thinking a lot about business again. How can it work for business.

For example, a company I have here in my midst, Oxford Creative, arose from building sites for the car manufacturer Seat. (They are searching for clients, so get on board quickly, as they are a small but effective team.)

I have been talking about twitter and many of my friends do not see the point.

But twitter, is less evasive, more rapid, more dynamic than any other social media tool.
I do not get hounded by it. I switch it off, its off. I switch it on, I have access to some great minds.

I found this How To Use Twitter Effectively for Business and Advocacy, which says a lot about its power, amongst many other posts, which have been floating around twittersphere.

I use it, because I can meet some interesting people, like @unclebobmartin, and @kentbeck, @bigballofmudd (Brian Foote). I like twitter because its less intrusive than phones, emails and facebook, but its powerful enough to communicate.

Tags: twitter, blogging, social media