Jonathan Crossland's Talkware

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

The majority of Software is quite multicellular. This sounds quite good, but in fact, its not even a small insect yet. or one could argue they are at the bug stage. Software tends to be rude, uncultivated, and unevolved, mainly due to LackOfEvolution.

One of the significant aspects of this, is that focus is granted to the development of the initial project, and then a handful of people (or if you are unlucky, just you), who are burdened with supporting it afterwards. This basically means "bug fixes until death" and lots of phone calls and emails later, you lose the lack of thought and action, but the software does not evolve. Software suffers from LackOfEvolution

Why do I say this
I say this because the vast majority of software only undergoes one full life-cycle. It may then get a smaller cycle of a patch or update, but most do not go to version 2 with the same code base. Version 2 tends to have very little of the original team members, and the code may very likely have completely rewritten areas. Version 3 even less of anything original. It may even have a new technology or language that it uses. Developers also enjoy writing their own code, rather than using other code, so this makes it easier to rewrite.

solution?
The problem is that the software does not get time to age, mature and be cultivated.
We need that extra time. An extra cultivation iteration is needed in all software teams, on any project. Create a planned version 1.1. Get your full team to conduct a special maturing cycle, where they add a few features, refactor code, shuffle things around. Plan it properly just as you would the first life-cycle.

LackOfEvolution for Teams

Software Teams can suffer from LackOfEvolution also. Developers can sometimes get caught in a project and not learn new things while they are busy on a project. You get to the end of a two year development and realize a few things have passed you by.

solution?
It is vital to stimulate debate about code, to have a trainer in for a day, to get show and tell sessions by members of the team, and other useful activities to counter act the stagnant waters. If you don't do SCRUM, have a SCRUM week, where you follow SCRUM for the week and evaluate it. Have a CompetencyFramework fro all developers with a plan on their evolution within a project and technology. We all need evolution, of character, skills and understanding, it is how we get better.

Tags: methodology, design, design patterns

updated:
So what would I think are the most important principles for building a Framework?
Here are my current ones, in no specific order. I plan on gathering a collection of these on my pages, but for now here are a few to go on.

A large percentage of the patterns, heuristics, principles for Frameworks will apply to standard software development.

1. Convention Over Configuration
2. Works out of the box
3. Fine grained objects
4. Hotspots
5. Coalescent Patterns (Composite patterns - GoF)
6. One Voice or (Too Many Cooks spoils the..)
7. Prototyping Applications
8. more on the link below..

Click for full list

Tags: frameworks, design patterns, coalescent patterns

Case tools, Modelling, UML, you name it, we have had the dream. We have built the tools. We have designed and bashed heads on semantics and special interests. Now the compromise is still not good enough. When a team of people begin to compromise design and philosophies you get a ViewPointMixture. A ViewPointMixture: a mixture of good ideas from various people for various reasons = Bad design (most of the time).

Not all good ideas work well together, albeit a good idea in itself. Most tools then become technical. UML is a technical specification, therefore the tool reflects a 1 to 1 mapping. I don't necessarily want that to always be the case. More...

Tags: uml, modelling, codegen

When we create objects and use config settings to ascertain context and things of that nature, it makes it harder to know what settings there are later on.

This is a significant fact across all things within software. Don't be scared to create small utilities and tools to aid your development. (As long as it does not affect your timelines).
Have you never got to a point in a project when you are wondering why something is not working and it ends up being a config setting?

Here is a simple solution for simple key/value settings More...

Tags:

Coming soon on TalkWare, it is another CodeGenWeek.

Now you may be aware, that TalkWare is the name of the PodCast show that I have started and you may also be aware of the Kent Beck interview. This is my first time doing podcasting and with all first time things, it is a learning experience. So I am starting out with a range of formats and interests and need your input to tell me what you want to hear on the show. Thank you, to a few of you who have sent me very supported emails already. It is much appreciated.

What is coming up on TalkWare?

CodeGenWeek II
This time, we are going to have 3 guests, coming to share their thoughts on Code Generation.
Once again if you have any questions, you wish me to pose to any or all of my guests, please send me an email and/or record and send me an mp3 of you asking the question.

We are going to be discussing Code Generation in today's current climate. Where will it go to next? What is the next generation going to look like?

Cyril Jandia lives in France, has a B.S. in Language Science and is a software developer interested in DSL's and OSLO.

Omer van Kloeten will be joining us from Israel. He has multiple projects on CodePlex, including Code Snippet Repository and CodeDom Patterns.

Oleg Sych, from Tampa Bay, Florida, is the creator of T4 Toolbox on CodePlex.

Tags: codegen, code generation, t4, codedom, oslo

"A revolution for editing code in .NET"

One of the most common Code Generation tools involve databases and are called O/R Mappers. This is going to change with the likes of OSLO and DSL's. But historically, Object-Relational Mappers have been the predominant force in CodeGen and they are usually CRUD based. (create, read, update delete) They come in various flavors and I have not used one before now that I still use today. That is, I could never find one that gives me enough freedom to design and implement my project the way I need to, and very quickly I leave them behind. Most have limitations, and don't actually do what it says on the tin.

For example, more than most try to sell you the idea, that it removes the database from you, you can talk to it via the objects, however, I have never found one, that I have not had to go “under-the-hood” to modify a Stored procedure or some aspect of the generated code. So if you do choose to use an O/R mapper, you must be sure, that you can make changes deeper down in the generated code. CodeGen is not good enough yet, to be a black-box tool

But thats one flavor of CodeGen. Other flavors involve Wrappers, Code Snippets, Designer Tools, and general utilities that can generate entire projects and/or layers and everything in between. This post, I would like to concentrate on Visual Studio .NET Code snippets.
Visual Studio.NET Code Snippets currently have a few problems. No editing tool, no built-in way of designing snippets easily. It is one way. It injects the snippet into the Editor and when done, forgets everything about the Expressions. The Refactoring Engine and the Snippet are not friends. They do not communicate.

Code Snippets

Lisa Feigenbaum - Code Snippets in Visual Studio
Ken Levy takes his camcorder over to interview Lisa Feigenbaum and get a look at the new Code Snippets feature in Visual Studio.

Code Snippets Solution applied to all code files, LIVE

A Code Snippet should not “lose” knowledge of the parameters/expressions. Anytime, I click on an Expression (example: PropertyName) that was inserted with a Code Snippet or NOT, it should still understand it. Refactoring would be automatic. Why should it be two separate tasks? Have you ever changed a Property Name, without wanting to change where its referenced?

Consider adding the “prop” Code Snippet. It asks you for Field and PropertyName. Now I believe that this is “kind-of” there for Visual Studio 2010.

But the key missing ingredient, is having our code “always aware”, especially of “expressions”. If you click on a Field it should highlight and as you make the rename change, it should alter your references automatically.

But a Code Snippet is only a small utility, but I wanted to use it as a small example of how code snippets need to keep context and knowledge of its injection, and in the same way Code generation in general has to be able to do this too.

If you generate a class for my person table in a database, and I change the class name, it should, by means of Code Snippet Expressions, Refactoring Engine, understand and align the change across to the database and the the code that references it.

Tags: code snippets, vs.net

Code Generation Network

CodeGeneration.NET | CodeGeneration.NET FORUM

Listen to CodeGeneration NETWORK - conference of 2007

Episode 1: UML vs DSL: A False Dichotomy?
Includes Steve Cook's emphatic view.

I absolutely love it. Truth with conviction.


Episode 2: The future of


Download the Episodes

Tags:

An old paper, but worth a read if you are interested in Patterns and CodeGen

Automatic Code Generation from Design Patterns
Frank Budinsky, Marilyn Finnie, Patsy Yu, Toronto Software Laboratory, John Vlissides, T.J. Watson, Research Center

Tags: