Lately I was asked to write a few words about Pflection. So I decided two write a new Blog Post.

What is Pflection?
Pflection is FDT View used for code review.

The view is separated in three columns.

First column contains information collected by FDT on elements you selected. Pflection reacts on selections made in Project or Outline View. Multi selection is also supported.

As you can see there are two kinds of collected data.
1. A list of a certain elements with a quantity
2. A list of OO and functional characteristics with absolute quantity and average distribution.

On metric selection in first column, second column will show the compound items.

In case of certain elements list user gets a quick view on names of elements and can open the element in source editor by double click. This way user may find poorly named elements.

When a characteristic item is selected, user will see the distribution list in second column and the elements compound in the distribution if one is selected in second column.

So how does Pflection help me to improve my design?

As already mentioned, you can improve the naming of your elements by browsing through element lists.
You can lookup the distribution of interface implementations and class inheritance depth.
I suggest deep class inheritance is not always a good solution and an interface should be implemented more than one time.
You also can lookup coupling of elements through Incoming/Outgoing Reference ratio.

Complexity of functions may be monitored by:
- number of method lines of code,
- number of parameters you may use to call this function
- number of blocks in a function
- number of conditions / branches introduced in function btw. this number correlates with number of test you need to get a 100% code coverage
- number of flow terminations

Thank you for your time and have fun with Pflection.

PS: I used funk-as3 for demonstration / screenshot creation.

In chemistry or in physics if you are making some experiments you are putting the subject in a controlled environment.
You do it because you want to avoid external complexity and side effects.

The same thing we do in software development by mocking interaction partners of the unit under test.

Software, in particularly object oriented program, is all about communication. Every method call (message passing) is a communication. You passing some arguments and receiving values or exceptions. Your behavior depends on your communication partners because your algorithm will take different paths because of the return value or a thrown exception.

So if you want to make sure that the behavior is all good, you have to control what your partners are telling you. It is a part of the test scenario and of precondition to specify what will be received by the unit under test.

Another side effect that can be checked by a controlled environment is what your unit under test is telling it’s communication partners. That could be some computed values that you can’t check after the whole algorithm is executed.

If you make a Sequence diagram of the unit you are testing you should see all the communication options you have.
There you can also see if the communication can be controlled. If the communication partner is created by the algorithm under test you have no chance to controls its output and validate call parameters that are passed to it.

In this case a field and IoC is your friend. Same thing applies to Law of Demeter. It is easier to stub / control if you Only talk to your immediate friends and not to the friends of friends because in this way you also have to control friends of friends.

It is an interesting concept.
Document is a Tree.
A tree is an undirected graph in which any two vertices are connected by exactly one simple path. (Wikipedia)

Means that Graph based Databases must be more expressive than Document based.

Interesting…

http://neo4j.org/
http://www.hypergraphdb.org/index

http://www.infoq.com/interviews/jez-humble-continuous-del

I made some JavaScript research lately. Mostly for testing and QA.

Here are some outcomes:

The Mess behind JavaScript:
http://www.infoq.com/presentations/The-State-and-Future-of-JavaScript
now I also understand why ActionScript !== JavaScript

Best Testing framework in my opinion.
Jasmine
Jasmine and Maven
QA:
Lint

Pretty amazing stuff:

http://cappuccino.org/

http://www.sproutcore.com/

Those two are Apple made or inspired.

Do you know some more? Maybe different inspiration?

[Update]
here is a talk about HTML5 on mobile speaker also refer web frameworks at the end
http://www.infoq.com/presentations/mobile-web-50

http://www.infoq.com/presentations/Future-of-Programming-Languages

http://www.infoq.com/presentations/HTML5-Today

http://www.infoq.com/presentations/RDFa-Microformats

I am proud to present the V2 of my one and only iOS App that made it into AppStore :) .

I experimented a lot during the years with iOS. But there is always the gap between project and product.
A product needs at least an icon. And there you starting to think about a designer. Then you looking in AppStore if maybe someone else had the same idea and more time to develop it better and so on…

Anyway V2 is up and running, it is tuned for Retina Display and works only on iOS 4.1.
It is Portrait and Landscape based. In Portrait mode you have the puzzle and controls in landscape it is all about puzzle.

Also an interesting point. In first version I let the user adjust the number of columns and the gap.
But I cached myself that I never play around with this things. Normally you have something selected and you are just exploring photos from flickr by solving the puzzle.
So in V2 I made just 4 possible puzzle variations and it is also playing nicely with Apples GameCenter LeaderBoards.

Another thing that user were asking for was the ability to play offline – with the photos from there own.
An interesting technical part in this feature was that the photos made by iPhone4 are pretty big and I had a performance problem with them.
Thanks to this post:
http://vocaro.com/trevor/blog/2009/10/12/resize-a-uiimage-the-right-way/

I was able to scale the photos. Wouldn’t think that it is so complicated in UIKit.

Any way it’s up and running, enjoy if you have an iDevice :)

http://itunes.com/apps/lineupflickr

Shame on me!

I disappeared for a month but now I am back with some of topic stuff.
I will continue to work on MockitoViz as soon as I can, but now I want to write about some other pet project of mine.

Pflection is a view for FDT that shows some Software development metrics for selected project, package or what ever you selected in your project/outline view.
At the moment I implemented Pflection I was not aware of Sonar, but in my opinion the two projects has also different field of use. Sonar is a CI tool, Pflection other wise is development tool. The feedback cycle of Pflection is much shorter.

So what does Pflection can?

It watches you selecting elements(multi selections enabled) in Project or Outline View and shows aggregated data about selected items. For example if you are selecting a project it will aggregate the data about all the containing elements (libraries, source folders, packages etc..)

What data (metrics) we are talking about?

Metrics can be divided in following groups:
Source Containers:
- Number of Libraries (SWC)
- … source folders
- … packages
Compilation Units (Master Elements – representing the file):
- … classes
- … interfaces
- … functions
- … variables
- … constants
- … namespaces
Nested (hidden/local) Elements:
- … classes
- … interfaces
- … functions
- … variables
- … constants
- … namespaces
Type members:
- … methods
- … static methods
- … setter
- … getter
- … field
- … constantField
- … namespace
- … metatag
Object Oriented:
- Interface implementation rate
- class inheritance depth
Dependency based:
- Number of incoming references
- Number of outgoing references
Behavior (Function) based:
- Method lines of code
- Number of conditions
- Number of blocks
- Number of flow terminations

Now I would like to talk about the last three metrics and how they can be computed.
Lets start with the simple one – number of blocks.
blocks are code statements wrapped in ‘{}’.
So by providing the number of blocks in a function we can make assumptions about horizontal and vertical distance inside the function.
FDT has also a Parser that creates AST from source code.
Block is an AST element so we just have to walk throw a function AST and count the appearance of Block Nodes.

I wrote some Scenarios to test the visitor:

Scenario: Check an empty function
Given a function:
function foo(){
}
When applying Function Analyser
Then number of blocks is '1'

It’s pretty simple to test the visitor because there is no need of binding the function. But any way if your Visitor needs a binding based computations it’s better to delegate it to another Class and mock it out for the test. This way you also end up with a better responsibility distribution.

Here is another Scenario for block computations but than let’s move on

Scenario: Check function with nested if/else condition for blocks
Given a function:
function foo():void{
	if(true){
		if(false){
		}
	}else {
	}
}
When applying Function Analyser
Then number of blocks is '4'

Next metric I would like to mention is number of conditions.
This metric show how many ways your code can be executed and how many tests (at least) you should write to have a 100% code coverage.
I implemented all three metric computations in the same visitor for a better performance and because they all have the same responsibility – count appearance of some particular AST element.
The AST elements I am interested in for condition counting are:
all sort of loops, if and case statements.
I also included a try block because the code inside a try block can have different execution flows.
Oh and last but not least condition expression.
Here is a scenario

Scenario: Check a function with nested condition expression 
Given a function:
function foo():void{
	true ? true : false ? trace("a") : trace("b")
}
When applying Function Analyser
Then number of conditions is '2'

Number of flow terminations – this metric provides you with info how many exit points your function has. The more exit points your program has, the more aspects you have to keep in mind when you are reading it.
A simple void function has only one exit point.

Scenario: Check an empty function with void type
Given a function:
function foo():void{
}
When applying Function Analyser
Then number of flow terminations is '1'

A typed function has a termination when it has a return statement

Scenario: Check a simple typed function
Given a function:
function foo():int{
	return 0;
}
When applying Function Analyser
Then number of flow terminations is '1'

A termination point can also be a continue and break statement. Those are no end points for a complete behavior, but they merge two execution flows together.
A global behavior end point is also a throw statement.

Scenario: Check a void function with throw exeption
Given a function:
function foo():void{
	if(false){
		throw new Error("foo");
	}
}
When applying Function Analyser
Then number of flow terminations is '2'

All the scenarios can be browsed in FDT-OS project on google code website
http://code.google.com/p/fdt-os/source/browse/#svn/trunk/FDTPflectionTest/src/de/bomzhi/mz/pflection/model/scenario

So if you think there are some additional scenarios/features I haven’t thought of, please try it out and post it in comments.

© 2011 Max Blog Suffusion theme by Sayontan Sinha