Néstor Salceda

Dependency Injection with Tornado

2011-11-30T00:00:00+01:00

One of the most powerful patterns I use is Dependency Injection.

The main idea behind Dependency Injection is collaboration. Collaboration among objects for solving a problem. Do you remember divide and conquer algorithms? These algorithms works breaking down a big and complex problem into several sub-problems which become simpler and simpler and can be solved easily, then the solutions to the sub-problems must be combined to give a solution for the original problem. This is the goal of Dependency Injection, defining the way our objects are going to be combined for collaborating.

Let’s go with an example. We are going to write a web handler for inserting some data into a database.

The Code

from tornado import web

class InsertInDatabaseRequestHandler(web.RequestHandler):
    def initialize(self, mapper):
        self.mapper = mapper

    def post(self):
        entity = self._create_object_from_arguments()
        self.mapper.insert(entity)

    def _create_object_from_arguments(self):
        #...

This is the web handler. It receives a POST request with some arguments, builds an object and pass it to the insert method of mapper instance variable.

from tornado import web

connection = connection_to_database()

application = web.Application([
    web.url('/element', InsertInDatabaseRequestHandler, kwargs={'mapper': EntityMapper(connection)})
])

This is the application creation. It maps a URL with a piece of code.

With this code Tornado is going to give us a nice way for performing Dependency Injection.

The magic

So we start our cool application and we receive a POST request, next the post method in InsertInDatabaseRequestHandler is executed, then an entity object is built and passed to insert method in self.mapper and … CRASH!!

Traceback (most recent call last):
  File "<stdin>", line 2, in post
AttributeError: 'InsertInDatabaseRequestHandler' object has no attribute 'mapper'

Why does this never happen?

This is because every web.RequestHandler in Tornado has an initialize method that is executed as last step in web.RequestHandler constructor and receives the kwargs dictionary sent to web.url constructor as keyed arguments.

In other words, we are able to inject the dependencies of each web.RequestHandler subclass through its initialize method.

Quite simple, isn’t it? Were you expecting arcane magic or complex techniques?

How can this pattern help us to write clean code?

In first place, every class has an unique responsibility, a unique reason to change. We are talking about cohesion and orthogonality, because all work related with database is in the EntityMapper class and the responsibility for dealing with HTTP is in the RequestHandler. Perhaps some of you are thinking about the S in SOLID (Single Responsibility Principle).

In second place, I’m able to choose among multiple implementations of a given dependency at runtime. If we are a bit smart, we will see the D in SOLID (Dependency Inversion).

Dependency Inversion states that:

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.

Do you see the abstraction? Yes, the EntityMapper class, and perhaps some of you remember from P of EAA book. The main advantage is that I didn’t write anything about the database, I could choose among various strategies: Plain Files, SQLAlchemy, Redis, MongoDB or some mix, have you heard about Polyglot Persistence?

Consequently, I can write testable code. But this a topic for another post :)

Trying Twitter

2009-09-13T00:00:00+02:00

Although I'm not a fan of this stuff, I decided to give it a try: My twitter account

See you there ! :D

Several updates.

2009-09-02T00:00:00+02:00

Well, the 8th of January looks so far. That was the last time I wrote!

In fact, I hadn't a lot of spare time, and I'm getting involved in some uba-spiff stuff. In the work, I'm improving my C/C++ skills, and I spend some time writting some Ruby and Python (and looking a bit to IronPython too) code too :) I'm also getting involved with Agile Spain Community where I've found some cool colleagues.

Sadly, I haven't enough spare time to spend with my contributions to Mono Project, but I'd like to show some stuff. I started a repo in Gitorious with some MonoDevelop templates for developing rules for Gendarme (it's in a really alpha state !!).

I hope find more spare time in order to continue contributing, and writting several new posts :P And I'm thinking about creating a twitter account

Wind of change

2009-01-08T00:00:00+01:00

I'm not used to write about me in my blog, but this time is different.

My life is gonna to change now. Several months ago, I decided to decrease my study time, and start working, perhaps change the place where I used to live in. Now it's the time.

After looking for a job quietly, I've found a job in a company (or two) which looks really nice, and today I've received the last instructions. I will start the 19th of January. I never am scared about the changes, nor this time that accept the job implies move my living place to Madrid.

I feel I'm going to start a new chapter in my own book, a new life, new challenges, new colleagues, new place, new job... But I'm proud of myself, because I was a bit disgusted with my studies (be careful, I'll continue studying in the university, although it's a bit boring :P) and I decided change that; and I can say (in this moment) I have achieved it, and I'm excited and really happy.

However, I start a new chapter; it will contain a lot of references to the previous one. I will continue my university studies (my second degree), I will continue contributing with Mono, I will come back to visit my famliy and I continue keeping the relationships with my dear friends and colleagues.

Perhaps a bit philosophical phrase could be:

The past escaped you can't do anything for that, it reflects your present. But won't exist the future if you are walking backwards.

Just listen to the wind ...

Gendarme and NAnt integration.

2008-10-23T00:00:00+02:00

Yesterday afternoon I was working in NAnt and Gendarme, and I published a piece of code that allows run Gendarme in NAnt, with a more sophisticated syntax than using exec tag. You can find it in the Gendarme Google Group.

I would like to share with you a little screencast.

I've done showing how NAnt executes Gendarme.

Enjoy!

PS.- Thanks to Garuma for his post about Quick and Dirty solution for the wordpress posts!!

Do you imagine Gendarme documentation in Monodoc?

2008-10-16T00:00:00+02:00

As all people loves screenshots (me too) I would like to share the stuff I'm cooking now :)

It still needs a bit of autotools love, but enjoy the screenshot :)

debug_mode=ON, social network for developers

2008-09-30T00:00:00+02:00

Several days ago, we and some old colleagues created the debug_mode=ON project. Please, let me post the announcement:

I’m happy to announce the creation of a social network in Spanish for developers, the web is http://debugmodeon.com. For the moment you can write articles, rate them, comment an article and create groups, each group has a forum and the articles can be associated with the groups.

The user is the most important in our portal, for this reason a user can earn money publishing articles, you only need your Google Adsense id.

We have created debug_mode=ON based on the idea of the ton of different technologies that a developer can learn today. So, a user can creates articles about Mono or Cobol, about Agile methodologies, SEO, design patterns, or how to do anything. The groups were created with the idea of debate around a concrete subject or a general one (depending the group) all around the them of computers.

To do the site we used Python, it’s running on the service Google App Engine. We licensed our code under Affero GPL, so our code is Open Source.

debug_mode=ON is a beta version, we’ve opened a thread to get your feedback, ¡all the opinions are welcome!.

You can read the offical announce here.

GSoC ended!

2008-08-26T00:00:00+02:00

Well, a week has passed since the Summer of Code 2008 finished and I haven't wrote anything yet mainly because I took some holidays :) Now, with my fully charged batteries I can write a little summary and show some stuff I've done.

I will start by the beginning :P

There are new rules:

Avoid Calling Problematic Methods [IN TRUNK]
Attribute String Literals Should Parse Correctly [IN TRUNK]
Provide Correct Arguments To Formatting Methods [IN TRUNK]
Declare Event Handlers Correctly
Instantiate Argument Exception Correctly [IN TRUNK]
Call Base Methods On ISerializable Types [IN TRUNK]
Implement ISerializable Correctly [IN TRUNK]
Mark All NonSerializable Fields [IN TRUNK]

There are 7 new rules in the SVN and the other is in the mono-soc-2008 svn, because I want review it in order to avoid false positives and commit code that works :) Almost of them, are rules which deals with the implementation and I think they are more useful to the other mono developers.

In the second place, I should say something about the reporter.

The reporter is a tool which takes the gendarme reports, in xml format. The report is passed to a pipeline (you can write your own!) and the pipeline applies some actions (you can write your owns too!) to the input and the input is transformed to other documents. Let me show you an example:

You runs gendarme against the corlib, then a report file is generated. You take the reporter and can generate a master index report or you can filter the defects per severity or ...

And in the third place, I automated the report generation and publication with a little bash script (which needs a bit more of love). The script runs gendarme, and pass the output to the report and I publish the results (more or less) frequently, and you can see a little example in: The classlib and the tools. It's a great chance for the newcomers for getting involved in the mono development :)

And this week is the Novell's Hack Week, and I hope get some time in order to talk and code with Sebastien, and I'm sure we will have more cool news :)

Hope you like all the news!

GSoC and Gendarme progress

2008-07-23T00:00:00+02:00

It was a lot of time since I blogged for the last time, and I should write some news:

Gendarme has reached the 0.2 release. You can read the release notes if you want more information.
I have passed the mid-term evaluation and I will continue adding rules, fixes, trimming down false positives ...
I'm generating with more or less frequence, some gendarme reports applied to the base class library and for other mono tools. This help me (I hope others too) for write new rules and for trimming down false positives. When I start to publish them daily I will put the link here :)

Summer of Code and Gendarme

2008-06-04T00:00:00+02:00

Google Summer of Code started the previous week, I can't believe I haven't blogged anything yet about the topic.

Let me talk a little about me, my name is Néstor Salceda and I'm studying Computer Science and, perhaps, someone will known me yet because this is my second year as student in the Summer of Code, the first year was wonderful and I decided apply other time :)

This year, my goal is to enhace Gendarme in order to be more useful to the Mono Project itself. For achieving this goal I have identified 4 key tasks:

Apply the existing rules.
Write new rules, putting special effort in write useful rules for implementing the class libraries.
Apply the new rules to the class libraries.
Automated Gendarme Reports generation and publication.

And finally, good luck for all students, and thanks to Mono Project for the opportunity :)

Random thoughts about the Gendarme Rule Day

2008-04-27T00:00:00+02:00

Well, I'm proud to say that the first edition of the Gendarme Rule Day has been a great experience and it ended successfully.

Also give a big thank to all people that was yesterday in the IRC with us (you rocks dudes!). Thanks for your time, thanks for your ideas, thanks for your presence, thanks for the thanks, thanks for the laughings ... thanks for all.

Numbers:

In this edition, if my review doesn't fail, we have 10 more rules and 3 nice enhacements to existing rules. And a lot of new ideas for great features. And also we have new friends and 2 new rule makers: Cedric Vivier and Andrés.

Next steps:

Well, by myself, I should start finishing several tasks I had started in the past:

Gendarme and NAnt integration
Message Chains Smell
A new way to express custom parameters to the rules in the XML file

And for finishing, I'm proud of being part of the Gendarme Team, thanks mates for the reminders, thanks for your help planning, giving nice tips, staying there and writting new rules. All I can to say is that we can't stop rocking ;)

April 26th: You Rule Day!

2008-04-16T00:00:00+02:00

The Gendarme team is proud to announce the first edition of the Gendarme Rule Day.

If you have a nice idea for a rule which you'd like to write or discuss.
Or if you don't have a specific idea but you'd like to try Gendarme and write a new rule.
Or if you'd like improve an existing rule.
Or if you want to learn more about Gendarme ecosystem or Gendarme developer's and fans ...

Please join us April 26th in the #gendarme IRC channel (in irc.gimp.org) for an interactive, collaborative and intense rule writing effort.

We will be there with you!

Gendarme and NAnt

2008-03-01T00:00:00+01:00

Yesterday night, before a week without any free time, I decided spent some time on Gendarme.

I decided spent some time on integration tasks with others applications (NAnt, XBuild, CC.NET ...) You can read the thread on Gendarme Google Group. And I started writting a Gendarme Task for NAnt.

By the moment, as I can't capture all in an screenshot, you can see it in action in a screencast:

Note that it's only a prototype, and is under heavy development and it's far away to be a usable stuff (by the moment).

Gendarme.Framework.Rocks Rocks!

2008-01-17T00:00:00+01:00

In the Mono Summit the Gendarme Team discussed about the features for the next version. We have a lot of new ideas for improve the framework. The main targets, for the framework, are the following:

Make simpler write rules, and easier to understand.
Make rules uniform, reduce code duplication, easy testing.

These topics are a bit abstract and is a hard task get it completed. But I believe this is the first step for achieve these topics.

The main problem when we are writting new rules, is the code duplication. There are several things we should prepare before write the rule logic. By example, when a rule is applied? We have a lot of scenarios before appliying the rule, if the method is anonymous doesn't make sense check about the naming conventions, or if a rule must check only the setters. And is always the same code, repeated one time, other time, another time ...

It's easy to understand that this code should be extracted to other class but, where should we put this code? The first impression was create static helpers classes, then you can get this code in the rules:

public MessageCollection CheckMethod (...)
{
    if (!MethodHelpers.IsSetter (method))
        return runner.RuleSuccess;
    //Imagine more rule logic
}

It's okey, but if we use static classes with static methods and thinking a bit ... Eureka! We can use extension methods to Cecil types, following the JB's Mono.Rocks, and the rules looks like:

public MessageCollection CheckMethod (...)
{
    if (!method.IsSetter ())
        return runner.RuleSuccess;
    //Imagine more rule logic
}

Beautiful code, isn't it?

Then, Sebastien and GHOP participants (Daniel Abramov, Adrian Tsai and Andreas Noever) implemented some of these Rocks (Good work guys !). The Rocks have unit tests and documentation, and we can use it for concentrate our effort writting more complete rules (click the image for a bigger size).

Finally, as all people loves screenshots, this is one screenshot of Monodoc showing the rocks documentation:

After the Mono Summit 07

2007-12-04T00:00:00+01:00

Wonderful, incredible, fantastic, amazing... I haven't enough words for describing my first Mono Summit.

The first day, I was really excited and a bit nervous because I didn't know anyone, but quickly I found Sebastien and JB and I sat by them (thanks you for all guys!) and we started talking, and hacking.

I also can see other people from the Mono-Hispano community (Andres, Carlos, Juan Ramon ...) but I missed Marcos a mate from the GSoC, I didn't meet you, but I hope the next time we will meet.

All talks also was really interesting: MonoDevelop, NUnit, Boo, Db4o, C# 3.0, Moonlight, Build Service, Boxerp, Debugger ...

Summarizing, the best: all the people. Thanks you very much!

Finally the last day, we discussed the new features for the next Gendarme release, you can see it here. There are some killer features and a lot of new ideas.

More Gendarme progress

2007-11-22T00:00:00+01:00

Since the last post talking about the project files for MonoDevelop, there are some progress that should be mentioned:

All rules are fully documented. You can see it in Gendarme Main Page and in Gendarme Google Group
We have fixed some bugs in the rules.
Added the Moonlight profile.

And the next week is the Mono Summit 2007. I'm really excited, because I have the chance to meet face of face to all the Mono Team (and my Gendarme colleagues), I can talk with them, I can learn a lot of things from them, improve and perhaps hack together.

MonoDevelop project files for Gendarme.

2007-10-09T00:00:00+02:00

This last week, we have been improving the build system and updating the project files for MonoDevelop and Visual Studio. This means, that you can use MonoDevelop or VS for explore the project and also for writting new rules. However this improvement is still under heavy development, you can see an screenshot:

Sebastien has merged more rules from the GSoC 2007 (from Nidhi and Lukasz).

Some Gendarme Progress

2007-10-02T00:00:00+02:00

Well, since the Pencils Down Report for the Summer of Code I haven't written anything about Gendarme. I have continued contributing, as I wished, and there's time for write a bit about the progress.

The rules for my GSoC has been merged, and there are more improvements:

Install Gendarme.Framework.dll to be reusable with new runners and pkg-config.
Support inclusion and exclusion of rules.
Added a new profile.

Step by step, the first feature allows developers to compile their runners with the -pkg:gendarme-framework modifiers to [g]mcs.

The second one, allows users to create their custom rulesets and adapt the existing ones to their needs. By example: Imagine a company that uses Gendarme to check their code. Then they can choose the rules that they apply.

If, by example, you like check the CodeDuplicatedInSameClass smell and AvoidLongMethods smell, but you doesn't like apply the AvoidSpeculativeGenerality you could do it simply:

<ruleset name="custom">
    <include="CodeDuplicatedInSameClassRule | AvoidLongMethodsRule" from="Gendarme.Rules.Smells.dll"/>
</ruleset>

And the third one, is the Mono BCL profile. This profile is intended to use with applications or libraries where the public API isn't under our control, by example Mono.

Gendarme Tasks. Pencils Down Status Report.

2007-08-21T00:00:00+02:00

Sadly, the Summer of Code 2007 has (quasi) finished. This is the time for fill the surveys and check the code.

Personally I have enjoyed a lot contributing with this project and I would like continue contributing with this project, there are some work to do and a lot of rules for implement and I would like continue working in this area.

A briefly summary of my contributions:

A rule for don't swallow errors catching non-specific exceptions.
A rule for check that Attributes end with Attribute suffix.
A rule for check that enums doesn't end with enum or flags suffix.
A rule for check that a enum flags uses a plural name.
A rule for check that a enum uses a singular name unless are flags rule.
A rule for check for unused parameters.
Two rule for check that doesn't exist code duplicated.
A rule for check the class length.
A rule for check the methods length.
A rule for check long parameters list.
A rule for check the presence of speculative generality.
A little gui for a cecil based tool for count and get some numbers for the classes: Number of methods, number of fields, number of lines per method ...
A patch for gendarme for allow set properties in the rules.xml file.
A little patch for Cecil.FlowAnalysis for allow try - catch -finally blocks in the flow analysis.

Then, I have learnt a lot of stuff: I have learnt about FOSS projects, how these projects works, I have learnt about Cecil and Gendarme, I have learnt C# and CIL, it's amazing.

I want thank all people that helped me, specially Sebastien, my mentor, for his patience everyday, his coding lessons, his help, his comments ... I also want thank all people that has helped me, Alan, Chris, JB Evain, and my colleagues working on more Gendarme stuff, Nidhi and Lukasz. And I'm sure that I will forget some names, please apologize me. Thanks to all.

And finally, thanks to the mono project for accept my application and to Google for the Summer of Code.

Gendarme Tasks. Weekly Status Report #12

2007-08-17T00:00:00+02:00

This is the status report for August 12 - August 17.

Accomplished this week.

Following the Sebastien's wish, I have implemented the Avoid Speculative Generality Rule, the rule is now for the reviewing process. This rule is a large rule, because I should check several things.

The rule will check for abstract classes without responsability, unnecesary delegation and I have a small solution for the problem with the duplicated violations. I'm going to explain the problem, for example, in the speculative generality smell, I have some signs for detect this smell, one of them is that exists methods with unused parameters (generally reserved parameters), then some weeks ago, I wrote a rule for detect the unused parameters, then I will run gendarme and I can get 2 errors:

The error produced by Avoid Speculative Generality Rule.
The error produced by the Avoid Unused Parameters Rule.

Then, when a detect a fail, the message should be clear and you should find the error quickly. If you get 2 messages, produced by the same error you can get confused with the errors.

Then, in the CheckType signature I get a TypeDefinition and a Runner. The runner contains a property for retrieve the rules applied, then I checked if the AvoidUnusedParameters rule will be executed (or has been executed), and if the rule is present I will skip the checking in the Avoid Speculative Generality rule.

Plans for the next week.

Sadly, the Summer of Code starts to end. I should upload the code, but I have a little bit of time for writting the next rule, I have posted the specification for the Avoid Code Duplicated In Sibling Classes. As I wrote other rule for check the code duplicated, I only should refactor and get the rule.

Challenges or problems.

Nothing special, the problem of the violations has been (half) fixed.

Interesting resource.

This week, I haven't any interesting resource.

Finally I want thank Sebastien, for give me advices and recomendations.

Gendarme Tasks. Weekly Status Report #11

2007-08-12T00:00:00+02:00

This is the status report for August 6 - August 12.

Accomplished this week.

Well, this week I have posted the rule for detect large classes, I have written it and I have posted for the reviewing.

Plans for the next week.

The next week I would like continue writting more smells, but I don't know which smell will be the following.

Challenges or problems.

This week, Sebastien and Chris advice me about the similarities among smells. By example: If you have a large class then the probability of that class contains code duplicated is greater, then you can have a violation for the large class and other violation for the code duplication.

Then the challenge will be determine how I can make sure I report the best / right rule violation. This problem is hard to solve, then I will think about it.

Interesting resources.

Yesterday, I saw an e-mail from Miguel, with a really interesting blog, here is the link.

And, that's all. Thanks to the people who has write comments to the rules.

Gendarme Tasks. Weekly Status Report #10

2007-08-06T00:00:00+02:00

This is the status report for July 30 - August 5.

Accomplished this week.

Well, after the review process, Alan suggested me that 10 is a big number for a long parameter list. Chris also suggested me if there are any way for change values for the rules without recompile.

Then I presented a solution and I wrote a patch for allow put some parameter in the gendarme file config. Then, with the patch you can specify some parameters for each ruleset, I like the results and the patch is pending for review.

I also finished the Avoid Unused Parameters rule. Alan suggested this rule in the list, and I liked it. This is because, sometimes, refactoring and removing some parameters, accidentally, I forgot remove the parameter from the method signature. This rule will check that you use all parameters in the signature.

Plans for the next week.

Well, for the next week I have some ideas. The first will be implement the message chain smell. This smell happens when you make a lot of chained calls. By example:

Foo anObject = new Foo ();
anObject.Bar.ApplyBaz (otherObject).MakeStuff ().Handle ().ToBar ();

There are a lot of calls in this line, and you can read more about it in this link. Chris has written some code for detect this chains, and I can reuse it.

There are other options, by example Detect long classes. This smell a bit complex to detect, but I believe I can do it. And with this smell, I have finished my 4 comples smells, and I can continue with others (Shotgun surgery, feature envy ...)

Challenges or Problems.

Nothing special, there was a problem detecting unused parameters. Specially with static methods, but I have fixed it and the rule will be reviewed.

Other challenge was, read, understand and modify the gendarme code; but the code is really clear and I like it. I really enjoyed a lot writting the patch.

Interesting resources.

Well, I have written a link some lines before. You can check it here is another taxonomy for bad smells.

Finally I want thank, all people that helped me, with ideas, with revisions or with other help. Specially my mentor, Sebastien, and Alan, and Chris and JB Evain for the corrections and advices in the IRC.

Gendarme Tasks. Weekly Status Report #9

2007-07-27T00:00:00+02:00

This is the status report for July 20 - July 27.

Accomplished this week.

This week I have been hunting a bug in the measurement tool. I have written some tests and I have detected and fixed it.

I also take some measures for choose the long parameter list, and I have decided to use 10 as MaxParameters in the rule. Personally, I prefer shorter parameter lists, but for the rule I believe that is a good measure.

I have sent the rules for the review process.

Plans for the next week.

For the next week, I will propose new rules. I like the Alan proposal for detect unused parameters. And I would like implement it.

As this rule is simple, I will propose a new rule for a new smell.

Challenges or problems.

None, this week I have worked in the tool; and I have detected the bugs and corrected it.

Interesting resources.

Well, I will post a link for the FxCorp tool. There are a lot of useful rules.

Finally, thank to all people that has commented the rules and suggest me some features and new rules.

Measurement Tool Screencast

2007-07-23T00:00:00+02:00

I have recorded a little screencast for the measurement tool in action.

Enjoy !

Gendarme Tasks. Weekly Status Report #8

2007-07-20T00:00:00+02:00

This is the status report for July 16 - July 20.

Accomplished this week.

With a little bit of delayment, I have written a little cecil based tool for measure the methods and the types. I need this tool for choose the values for detect long parameter lists.

Currently the tool takes measures from types and methods:

For Types: Lines per method, parameters per method, maximum lines in a method and maximum parameters in a method.
For Methods: Lines in a method and number of parameters.

I will post a screencast on Monday.

Plans for the next week.

I hope finish the current rule (Detect Long Parameter List) and I will continue with other smells.

Challenges or Problems.

None, this is a simple application. But, if anyone wants suggest me more interesting measures, I will be glad to read and implement them.

Interesting resources.

None, this week I have spent the time writting the application.

Gendarme Tasks. Weekly Status Report #7

2007-07-13T00:00:00+02:00

This is the status report for July 9 - July 13.

Accomplished this week.

This week, I have quasi finished the rule for detect long methods. Well, the rule simply count the IL instructions and compare with a MaxInstructions value. The big challenge for this rule has been choose the MaxInstruction value, this is because if you choose a little value you will get a lot of rule violations, and else if you choose a big value you won't get any violation. The two situations are useless.

As Chris Gameweld suggested me, I have to take care of the autogenerated methods too. The first approach try to find autogenerated methods simply if the IL code doesn't contain cond branches instructions. But this pattern isn't always true, by example Stetic generate a if statement. Then, I have collected some well known autogenerated method names, and checking them (and their types) I can know if a method is autogenerated.

I only have to check the types, and I will get the rule ready for the reviewing.

I also have proposed a new rule for a new smell. The rule is Detect Long Parameter List. The rule should check if a method contains a lot of parameters, and the big challenge will be (also) choose the value for the parameter numbers.

Plans for the next week.

Well, I have to finish the rules and go forward with more smells. I haven't decided yet what will be the next smell.

Challenges or problems.

None, for measure the methods I have chosen a little bit more of a screen. I have get the magic number rounding up to 170 IL instructions.

I have to get the upper limit for the long parameter list. But this time, I will measure and compare the results with some software metrics, because IMHO I can get better conclusions.

Interesting resources.

I have the same resources that the last week.

I want to thank to Lukasz Knop and to Chris Gameweld that suggest me measures, and some corner cases.

Gendarme Tasks. Weekly Status Report #6

2007-07-09T00:00:00+02:00

This is the status report for July-1 to July-8.

Accomplished this week.

This week I have finished the first scenario for detect smells in the code. I have finished the rule for detect code duplicated in same class. Finally I have decided don't use Cecil.FlowAnalysis assembly, because with the new approach I need know only a few details about flowanalysis and I can get directly with Cecil. I'm really impressed with Cecil. Although the rule is finished, I will improve more the code for detect code duplicated, because is the core for other two rules: Detect code duplicated in two sibling subclasses, and detect code duplicated in two unrelated subclasses.

I also have proposed a new rule for detect a new smell. The rule should detect long methods, the biggest challenge for this rule will be to choose correctly the size for determine when a method is long. A few hours ago, Chris Gameweld sent to the group a mail with a cool suggestion.

Plans for the next week.

Well, the next week I will finish this rule, and I will propose other rules. I have a lot of smells for detect.

Challenges or problems.

Yes, the biggest challenge is determine the maximum method size. By the moment I have thought of an screen as the reference measure, if the method is bigger then the rule will warn you.

Interesting resources.

Yes, I have a lot of interesting resources.

For someone that is interested in smells, you can check this link

Also, you can read some books about, by example:

Refactoring: Improve the design of existing code. In Amazon
Refactoring to Patterns. In Amazon
Code Complete. Second Edition. In Amazon

Finally thank, all people that have written advices, or comments for the rules.

Gendarme Tasks. Weekly Status Report #5

2007-06-30T00:00:00+02:00

This is the status report for June 24 - June 30.

Accomplished this week.

This week I have written a little patch for allow try / catch blocks in the Cecil.FlowAnalysis assembly. I have sent the patch to the mono-devel list, because I would like know if I'm doing the testcases correctly and separating the blocks well.

Plans for the next week.

I have seen other way for implement this funcionality, because I have read about the Exception Handling in the Ecma document for CLI, and I can get a better implementation. I would like finish this task on Tuesday, because I'm spending more time in this task and I am a bit delayed. I will put all effort in finish it.

Challenges or Problems.

This week I haven't a lot of problems, only one; because I don't know where send the patch. But Sebastien answered my question quite well.

Interesting resources.

Yes, the Ecma-335 document helped me a lot.

Gendarme Tasks. Weekly Status Report #4

2007-06-23T00:00:00+02:00

This is the status report for June 18 - June 23

Accomplished this week:

This week I have continued with the Code Duplicated smell. I'm trying detect duplicated code reading IL instructions and checking against others. Is a simple approach and I can detect some code duplicate. I'm also impressed with Cecil, it's a great library and I love the Visitor pattern.

But I'm not happy with the results, because detecting branches is difficult and I can't detect all code ways.

By example: Suppose a simple if statement:

if (myList.Contains ("MoreFoo"))
        myList.Remove ("MoreFoo");

The IL Code generated is the following:

IL_0000:  ldarg.0
IL_0001:  ldfld class [mscorlib]System.Collections.IList Test.Rules.Smells.ClassWithCodeDuplicated::myList
IL_0006:  ldstr "MoreFoo"
IL_000b:  callvirt instance bool class [mscorlib]System.Collections.IList::Contains(object)
IL_0010:  brfalse IL_0025

IL_0015:  ldarg.0
IL_0016:  ldfld class [mscorlib]System.Collections.IList Test.Rules.Smells.ClassWithCodeDuplicated::myList
IL_001b:  ldstr "MoreFoo"
IL_0020:  callvirt instance void class [mscorlib]System.Collections.IList::Remove(object)
IL_0025:  ret

I drop out the ldarg, ldfld, ldstr and others, and I get the information for compare Instruction Pairs. And If I write only:

myList.Contains ("MoreFoo");
myList.Remove ("MoreFoo");

The unique difference in the IL code was that I haven't the branch instruction. I can detect simple duplications, but only detecting these ones won't be useful.

Then I decided:

Plans for the next week.

Following the last lines, I have decided change the code representation, and I will use Control Flow Graphs for make some FlowAnalysis and obtain more information for detect code complete.

I can get from the CFG the blocks and check blocks. And better, I can try detect common subsets for each block. With this approach I believe that I can write a more complete analysis and detect the code duplication better and in a easier way.

Challenges or Problems.

Yes, a lot ! For the first, I have decide use the Cecil.FlowAnalysis assembly (placed in the cecil module in mono svn) for obtain the CFG, I will save a lot of work using this library. But I have a little trouble.

Yesterday afternoon, I started working on the CFG analysis, then I started building the graphs; and I get a surprise:

1) Test.Rules.Smells.DetectCodeDuplicatedInSameClassTest.TestClassWithCodeDuplicated : System.ArgumentException : Exception handlers are not supported.
Parameter name: body
  at Cecil.FlowAnalysis.Impl.ControlFlow.FlowGraphBuilder..ctor (Mono.Cecil.MethodDefinition method) [0x00000] 
  at Cecil.FlowAnalysis.FlowGraphFactory.CreateControlFlowGraph (Mono.Cecil.MethodDefinition method) [0x00000] 
  at Gendarme.Rules.Smells.DetectCodeDuplicatedInSameClassRule.ContainsDuplicatedCode (Mono.Cecil.MethodDefinition currentMethod, Mono.Cecil.MethodDefinition targetMethod) [0x00000] 
  at Gendarme.Rules.Smells.DetectCodeDuplicatedInSameClassRule.CheckType (Mono.Cecil.TypeDefinition typeDefinition, Gendarme.Framework.Runner runner) [0x00000] 
  at Test.Rules.Smells.DetectCodeDuplicatedInSameClassTest.TestClassWithCodeDuplicated () [0x00000] 
  at &lt;0x00000> <unknown method>
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[])
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] 
  </unknown>

Ouch ! Then I believe that I have to write a patch for allow exception handlers and build the graph.

Interesting resources.

This week, I only have an interesting resource that hope helps me with this work, the dragon's book :)

Finally thanks to Sebastien for solve my doubts. Also thanks to all mono people, every day I enjoy a bit more working with this great people.

I want also congratulate the Moonlight accomplishmet, I want try this technology!

Gendarme Tasks. Weekly Status Report #3

2007-06-17T00:00:00+02:00

This is the status report for June 10 - June 17

Accomplished this week.

This week I have proposed 2 new rules. The first one is called "Don't swallow errors catching nonspecific exceptions". And the second is the first into the smells set, it's called "Detect code duplicated in methods that belongs to same class".

I'm working hard in this last rule.

Plans for the next week.

The next week, I would like finish this first smell rule. And purpose other rules too.

I have made a plan for finish this first smell.

I've identified 3 main scenarios:

Code duplicated in the same class. This happens when you have 2 (or more) methods that have the same expression. You have to do a "Extract Method" and invoke the code from both places.
Code duplicated in two sibling subclasses. Then you can remove the duplication extracting method and pulling it up. But there are other refactorings to apply here.
Code duplicated in two unrelated classes. This scenario can be more difficult to identify. And I will study it later.

Challenges or problems.

I have a really interesting challenge, detect code duplication often isn't easy and there are a lot of stuff to do. Luckyly with the unit test you can see quickly if you get your goals.

By the moment, I'm writting this detector using a peephole. With this approach I can check the IL directly without build an AST and I can detect the smell in any language (VB, Nemerle ...)

Interesting resources.

This week, I have a really interesting resource: Code Nose Thesis. This project inspects Java code for detect some smells too. Thanks to Chris Gameweld for the link.

I want also thank all people that have written comments for the rules.

Gendarme Tasks. Weekly Status Report #2

2007-06-11T00:00:00+02:00

This is the status report for June 4 - June 10.

Accomplished this week.

I have proposed 2 new rules. This rules deals with enums; the first rule, was "Do use a singular name for an enumeration, unless its values are bit fields". The second one, was "Do use a plural name for the Flags Enums".

I have to write a fix for the singular and singular checkings.

Plans for the next week.

The next week, I will purpose a new rule for check the empty catch statements and start working with Cecil and IL.

I also would like start the code duplicate smell.

Challenges or problems.

This last week, I was really busy. This week, I will write more code.

Interesting resources.

The first, thanks to Brian Nickel for the links:

Also thanks for all people who has written comments for the rules. (Last week, I forgot write this, I'm sorry).

Gendarme Tasks: Status Weekly Report

2007-06-04T00:00:00+02:00

Accomplished this week.

This week, I have learnt some stuff more about Gendarme and Cecil. I have learnt the differences about TypeReference and TypeDefinition, and how Cecil resolves the assemblies.

I also learnt about Gendarme framework, I have looked the source code, and I have understand better how gendarme applies the rules.

Plans for the next week.

For the next week, I want finish some simple tasks, 2 or 3 or 4 anyways. And if I have finished these tasks I would like start with the smells.

The first smell will be the duplicated code. Then, I will learn more about Mono.Cecil.Cil namespace.

Challenges or problems.

The first problem came up with the TypeReference and TypeDefinition difference. Sebastien helped me a lot, because he explained the differences and the problems quite good.

Interesting resources.

I have this link that it's a really interesting lecture about enums, and in general about coding guidelines.

First impressions working with Cecil / Gendarme

2007-05-20T00:00:00+02:00

Well, last week I have spent some time learning Cecil and Gendarme stuff. I've written my first draft for checking a simple rule and achieve some knowledge about these two technologies. I really enjoyed a lot learning these technologies.

I'm going to say my first impressions for each techonlogy.

Gendarme is simple. Writting new rules is easy. You only have to implement an interface.
Gendarme is well named. If you want to create a new rule for check types, you will implement the ITypeRule interface. If you want to create a new rule for check methods, you will implement the IMethodRule interface.
Gendarme isn't intrusive and is powerful. You can write the rule that you want. You can write simple rules, and also, you can write really complex rules.
Gendarme is integrated. You can use gendarme with different development tools (you can create a NAnt task, you can use with Makefiles) and programming language (you can use VB.NET, you can use Boo).
And finally, Gendarme is in continous improvement.

I also think Cecil is a great framework too. By this moment, I think it's simple, it's fast and it's easy deal with it and you have a lot of documentation. I can't write more about Cecil, because Cecil is bigger an I will need more time to learn it.

Well, the first rule that I've chosen to implement is that Attributes ends with "Attribute" suffix.

This rule will check that the new attributes ends with "Attribute" suffix. You can see the reference in C#Language Specification.

Some examples:

Good:

public class CustomAttribute : Attribute {
}

Bad:

public class Custom : Attribute {
}

In the next days, I will add more test cases and I will put some links to source code to prove that it's really easy write this rules with Gendarme and Cecil.

Buildix

2007-04-27T00:00:00+02:00

Some days before my travel to Valencia, I have seen this amazing tool.

Buildix is a GNU/Linux distribution that combines some tools:

And all of them with an little apache front end for manage users for all components. I have seen the demo and I decided to try it.

I'm using trac for my projects and subversion, I think that it's a great combination. Trac forces you to think for tickets, you could think tickets as little things that add value and for register bugs too. Then you can only concentrate in these tickets and no write more extra code that doesn't add any value.

Then, the subversion server allows you to drop code ownership; and in a little time you could share your changes and patches. And one interesting thing about trac and subversion, the hooks. With the hooks, you can write in your svn message:

refs #ticketNumber

Stuff, Foo, Bar ...

And then, you can go to the ticket URL in trac and see this changes as comments, with this little things you can concentrate about the value. You also can close a ticket.

The only thing that I don't know is CruiseControl, is for create automated building and test the application (also pass a pretty printer for code), by this time I have only seen working with Java. I have seen CruiseControl for .NET. I don't know if there are any platform for get continous integration in a more generic way, for example: For Java, you can use Maven, or Ant or Makefiles too, for Mono you can use NMaven, NAnt and makefiles too. I believe that one tool that be capable to build the entire project in an heterogeneus scenario, for example: If you are developing a C# application and build with NAnt, the tool take care of this and use NAnt for compile. The same, if you are writing a Java application. The same if you are writing a C/C++application, using Makefiles.

I think we can abstract this component a bit more and get a more generic builder, with different backends.

And the last one idea for today, I have think about a distribution for developers. For example, the ubuntu people has the Sun Toolchain for write Java applications. Or the Mono VMWare images for test. Every developer write the code in a different way, but for example a distribution with libraries (log4net, nmock, nunit, mono, monodevelop ...) Or in the Java way a distro including (log4java, netbeans or eclipse, java, tomcat, jboss...)

And that's all for today.

Babuines in db4o

2007-04-15T00:00:00+02:00

Well, some weeks ago, I received an email from db4o. And as some babuine foundation components uses db4o as persistence engine I get a project space in the community.

The link.

Returning

2007-04-14T00:00:00+02:00

Yes, I'm returning.

I'm going to talk a little about me. My name is Néstor Salceda and I'm finishing my computer science studies. I'm interested in software engineering: concretely about refactoring, software testing, design by contract, compiler design and implementation and component software.

I have had other blog, but my local home server crashed some time ago. My last weblog address is invalid. This will be my new blog site, special thanks to Sergio Rubio, my dear Sysadmin.

In this blog I'm going to talk about my Google Summer of Code project. I'm going to write some Gendarme Rules for detect bad smells into the code. I may also write about others OSS stuff that I'm writing, for exmple the Babuine Component Model, this is a framework for develop MVC components quickly with Mono.

The smell concept is amazing, when I was reading the Martin Fowler's book called Refactoring. The smells really impressed me. I will write other rules too.

Okey, the last one; as Scott Peterson do, I'm going to post a photo of me.

Well, good luck for all the students that will write the SOC applications. And thanks to mono project for the chance.