DeusExMachina

Thought of the Day

claudio.figueiredo — Fri, 01 Aug 2008 20:47:14 GMT

Isn't loopback a redundancy?

If it's a loop wouldn't it be back anyway? :)

ASP.NET MVC Preview 4 Released

claudio.figueiredo — Thu, 17 Jul 2008 02:30:14 GMT

Read the Title
Grab while it's hot

Cheers,

ASP.Net MVC ActionFilters

claudio.figueiredo — Sun, 13 Jul 2008 03:20:00 GMT

I'm a lame blogger, I know. There's been more than two years that my friend Heynemann has been teasing me to post more, and it's starting to happen more naturally these times. The reason that I blog less than I'd wish for is that I'm crazy about coding. That's where I tend to focus most of my time, but I'll keep posting more frequently now. The reasoning behind this introduction is to assure all my three readers (you know who you are lol), that my series on .Net MVC will be continuing soon.

Action Filters - Why and How?

Action Filters are .Net MVC native way of adding intercepting capabilities to your application. It's a non-imperative way of adding some AOP to your Controller's Actions without resorting to AOP or IoC frameworks.

It's a sweet move on the part of the development team, and It's something that makes SoC and extensibility in .Net MVC very easy to implement.

Well, since the first time I've read about it, I knew it would be a perfect fit to integrate with ValEver.

ValEver (short for Validation Everywhere) was one of the neatest pieces of code ever produced by Bernardo and I had the pleasure of developing its integration with Windsor Container some months ago.

I'll try to give some examples here on how to use ActionFilters through implementing integration with ValEver and check on the benefits of this happy union. :D

ActionFilters provide a declarative way to access the executing context prior to, and following, the execution of an action.

It has a simple yet meaningful contract:

public abstract class ActionFilterAttribute : Attribute, IActionFilter{     // Methods    protected ActionFilterAttribute();    public virtual void OnActionExecuted(ActionExecutedContext filterContext);    public virtual void OnActionExecuting(ActionExecutingContext filterContext);    public virtual void OnResultExecuted(ResultExecutedContext filterContext);    public virtual void OnResultExecuting(ResultExecutingContext filterContext);     // Properties    public int Order { get; set; }}

Most methods are self explanatory but the important ones in what I'm trying to achieve are OnActionExecuting and the ActionExecutingContext.

That's the Pre handler of a Controller's Action call. Through it you can reach the Context and interact with it.

First thing I did, as any good developer should do, was a test. And so it came:

[ValEverActionFilter][ValidationShouldThrow]public ActionResult Index([Required("Supply a valid parameter")]string parameter1) {    return View();}

The ValidationShouldThrow and Required("Supply a valid parameter")] attributes are native from ValEver. The first being a marker to control behaviour, the second being 'The' validation of a parameter.

And from this test came my custom ValEverActionFilter:

public class ValEverActionFilterAttribute : ActionFilterAttribute {    public override void OnActionExecuting(ActionExecutingContext filterContext) {        base.OnActionExecuting(filterContext);    }

This small piece of code is all that's needed. Besides the business logic, which will be added later, all I need are the parameter values . Interestingly we have them. The neat trick here is the context.

The ActionExecutingContext allows us to direct access to info such as ...

//The calling Actionpublic MethodInfo ActionMethod { get; private set; } //The parameters and it's valuespublic IDictionary<string, object> ActionParameters { get; private  set; } //The request HttpContext public HttpContextBase HttpContext { get; internal set; } //Any data regarding the Routing used in the callpublic RouteData RouteData { get; internal set; }

... being able to manipulate almost anything inside the call's context.

Then again, I settled to test. But this time I need an integrated test between the Controller Action and the Validation through the call of ValEverActionFilter.

It happens that only calling the Action is not enough. And it makes sense. The controller is not so special alone after all. The ActionFilter calling is done on the Handler instantiation on ASP.NET.
"- So, no problem. How hard could it be?" TM

After lot of googling I found how hard it was. There's no out-of-the-box solution for this kind of test. So I set to make mine and it came as:

[Test]public void ShouldThrowOnInvalidParameters() {     TestingController controller = new TestingController();     Assert.Throws<ValitationFailedException>(() =>         controller.InvokeActionWithFilters<TestingController>(p             => p.Index(string.Empty)));}

The InvokeActionWithFilters Extension Method mimics what the ASP.NET does. Supplying defaults and calling the ActionFilter's hooked events in the right time with the right context.

Then I just had to write the business logic to my filter, and make tests go green.

public class ValEverActionFilterAttribute : ActionFilterAttribute {    public override void OnActionExecuting(ActionExecutingContext filterContext) {         var methodInfo = filterContext.ActionMethod;         AddValidationParameters(filterContext, methodInfo);         bool isValid = ValidationContext.Validate(filterContext.Controller) &&                                     ValidationContext.ValidateArguments(methodInfo);         ThrowIfRequiredByDecoration(isValid, methodInfo);         base.OnActionExecuting(filterContext);    }

Nothing more had to be done to have it interacting with the method call.
The filterContext.ActionMethod contains all the information needed. Parameters and it's values too.

Conclusion

So, despite the little trouble testing the ActionFilters with the call's context, it was easy extend and interact with one of the core aspect of a MVC framework and, better yet, keeping the concerns apart. Just some other cool things you can do with ActionFilters:

Cancel Action Execution
Interact with HttpContext
Override/fill parameters values
Set manually your own ActionResult

This opens so many possibilities that it makes me glad to see development going in this direction and delivering such good feats.

The full code of the sample application can be found here.

Cheers.

Lack of Tests

claudio.figueiredo — Wed, 09 Jul 2008 16:40:27 GMT

You might not hear me, nor Mr. Beck or anyone, but certainly you'll hear Dart Vader:

When life should imitate fiction :)

claudio.figueiredo — Sat, 05 Jul 2008 17:42:01 GMT

Somewhere, over the rainbow...

When fiction imitates life...

claudio.figueiredo — Sat, 05 Jul 2008 17:37:13 GMT

That's how one feels when he's reprehended for Unit Testing.

ASP.NET MVC Experiences 2, Overview

claudio.figueiredo — Mon, 30 Jun 2008 03:43:57 GMT

Setting expectations clear

What I'm trying to achieve here is not a "how to use" ASP.NET MVC or a Tutorial. For those I really recommend Scott Hanselman's videos which were my first source on the subject.

It's a hands on experience, a spike if you will, with the most prominent features of the framework.
It's a evaluation on how it works checking it advantages and disadvantages, from my point of view, and trying reducing some friction that I'm encountering on using MonoRail in my new project. Don't get me wrong, I have nothing against MonoRail, it is still the most mature, featured MVC implementation on .Net world and I would not find any friction on it if not checking on .Net MVC features.

Evaluation procedure

The criterias that I'll use in my evaluation will be, in the following order of importance:

Testability
SoC
Extensibility
Manageability

This analysis might not be linear, but these will be the focused points.

Overview

First time I heard about .Net MVC and checked out it's features, it looked to me a badly built copy of MonoRail. But I soon realized some very nice differences. Not on the project itself, but the behaviour of P&P conducting it's development. The way they positioned themselves eager to hear the community feedback led to great improvements over the three released iterations. That made me realize the fact that the similarities between them were not coincidental. Maybe the coincidences lie in the fact that they are both implementations of the same pattern, or more likely intentional (unless Filters and ActionFilters are both Design Patterns affiliated to MVC and I don't know ).

Anyway, this is good because the transition between them is almost seamless, but that's another topic.

Application Model

Almost everyone I talked about it, thinks that .Net MVC is sitting onto an Application Model of it's own. But the fact is that it's standing over the ASP.NET 2.0 Application model. Just as any other ASP.NET 2.0 application, it inherits from HttpApplication and has it's events and life cycle. In fact, the new cool routing system is registered just in Application_Start as any global register.

This allows some interesting (and freaking) options as running both WebForm and MVC simultaneously.

Even though I didn't expect a whole new web platform, I kinda hoped the separation would be a little more clear, not that this clouds the benefits that it provides. What really bother me is finding out that the standard ViewEngine, implemented by the ViewPage, inherits directly from our dear old friend System.Web.UI.Page. This open up even freakier possibilities. The fact that you can do the same funky thing that you do with a WebForm on a MVC View really scares the hell out of me.

First thing a tried when I find that out, was: add a Server form, an asp:button, an event handler and, Voilá: - Back to the same beach we've been swimming the past few years. I know that the fact the you could do something doesn't mean you should or would do it, but it gave me shivers anyway.

This also showed me that you could add any WebControl you like on the Page, and work with it freely as you would on WebForms but in fact you wouldn't like, more on that later.

Views

As said before, the default ViewEngine is basically a HttpHandler inheriting from the standard Page model. That said, one may conclude that anything you can do on a Page could be done on a ViewPage and most can actually be done. Here a some observations about this cross model that I checked:

The layout scheme, as expected is the same MasterPage mechanism used in WebForms.
Custom controls can be used the same way if you add a server form to the View.
Yes YOU HAVE VIEWSTATE, but only when adding a server form to the View, otherwise you get a nice clean html to work with.
You can use UserControls inside a ViewPage, but you'll end up with the whole ViewState/ServerForm stack polluting to your code.
You've got tracing enabled just as a WebForm.

The above issues worried me a little. ... mixed up model but spaghetti code?

Then again I remembered that's it's a Microsoft Product anyway. No rants here, just saying that Microsoft is not a charity and as such can't avoid cathering for the main customers in their current business model. This is just something I (and you reader) should bear in mind while reading this.

The good thing here, is that the View layer was nicely built. Although they allow more than I would like, what is done here is done in a beautiful way. View testing has been somewhat neglected on implementing MVC applications, but here we get a stronger model which we can test and extend in a natural way.

Some key points on Views:

Convention over Configuration

The first thing I noticed, and one that made very happy is that ASP.Net MVC Views and setting approach follow strictly the CoC principle. It's is such on MR and should not be changed, so common sense prevailed here for the good.

The rule here is putting your views on /Views/{controller}/{action} and nothing more needs to be done. It can be changed setting a new ViewLocator, which is a resolver for View's paths.

Even though everything seems the same, one addition that I really liked is the Shared Views concept, which is so obvious that I'll refrain from explaining.

The introduction of the concept of Typed Views.

Binding a View to a model seems very natural on MVC. And every view is bound to a model indirectly. The introduced change allows you to strongly-type your View's Data to it's own Model, thus making it more intuitive than generic views, that most of the time aren't really generic. Let's check how's that works.

That's the code for a view called List that'll be rendered by the List Action of the Home Controller.

        1: namespace Stormwind.MVC.Template.Views.Home {

       2:     #region usings

       3:  

       4:     using System.Web.Mvc;

       5:  

       6:     #endregion

       7:  

       8:     public partial class List : Viewpage {

       9:     }

      10: }

And that's the Template:

       1: <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="List.aspx.cs"
           Inherits="Stormwind.MVC.Template.Views.Home.List" %>

       2: <ul>

       3:     <%

       4:         foreach (var pair in (IList<string>)ViewData["listItem"]) {

       5:     %><li>

       6:         <%= pair %></li>

       7:     <% } 

       8:     %>

       9: </ul>

There's two important points here:

The first is 'public partial class List : ViewUserControl', notice that the view inherits from a specific base class. Among other things, this base class contain a property call ViewData. ViewData is nothing more than a KeyValuePair collection that is used to interchange data between the controller and the View. It's almost exactly the same as a MonoRail property bag.
The second is ' var pair in (IList<string>)ViewData["listItem"]'. Notice the cast here. As an untyped collection, ViewData items should be casted before used in a not so intuitive way. Worst of all making refactoring harder and the view error prone.

The concept of Typed Views, come to solve these issues. Check it out.

       1: public partial class ListTyped : ViewPage<List<string>> {

       2: }

Notice that the view now inherits 'ViewUserControl<List<string>>' allowing us to:

       1: <ul>

       2:     <%

       3:         foreach (var pair in ViewData.Model) {

       4:     %><li>

       5:         <%= pair %></li>

       6:     <% } 

       7:     %>

       8: </ul>

The inherited View sets the Model allowing us working more naturally and refactoring friendly now.

The ability to easily create and change a ViewEngine.

Creating and changing View Engines in MonoRail is not too difficult, but changing them in runtime is a little painful and doing that through Windsor makes it feels makes it feel unnatural and definitely not the expected behaviour, or at least one that requires more configuration than expected.

Creating a new view engine is incredibly easy, since the IViewEngine contract only has one method to implement - The RenderView method.

Of course, this post does not sums everything that the MVC Framework has to offer, but believe me, there's not much more either. You'll see soon in another post.

Well, Views are not that different from MonoRail or other MVC implementations, and given you have the ability to implement your own, it's a very flexible structure.

Next post: Controllers.

Stay tuned.

ASP.NET MVC Experiences - Part 1, The Setup

claudio.figueiredo — Thu, 26 Jun 2008 20:09:54 GMT

First of all I did what as every developer experienced in the RTFM methodology should do I went to it's Site and download the installer.

As I didn't found the binaries and was not in the mood of build the source (oh yeah, there is a source available for a change) I've downloaded the Installer just to check it out.

As a I installed the package, the usual NNF*, I was currently happily surprised to find no reference in the GAC. Only changes noticed so far were a new Visual Studio Template called ASP.NET MVC Web Application and a Start Menu Item Microsoft ASP.NET MVC Preview 3 which leads you the a folder containing the set of assemblies needed to run a ASP.NET MVC Application. (Duh!)

Normally I would go my usual way, creating a new structure using a Stormwind Project template and setting the references, but as I've been having a nice user experience so far I've decided to take the full trip MS induced experience.

Open up Visual Studio, selected New Project, Visual C# / Web and ASP.NET MVC Web Application named my Project , and then the first surprise:

Yes, it's a nice change see anyone at MS thinking in Test First, but the only test framework supplied is the MS Test. First I got a little angry, but then I realized that it's a MS product after all. :)

Well I'm a NUnit guy and as such I started digging how to make ASP.NET MVC works with another test framework.

After taking a look at it, and checked out it really works, I decided it was not worth it.

The main issue is exactly the wizard that, for some arcane reason, only is setup to show the Test Framework of your choice, changing a registry key.

Hope you now I didn't like it a bit, so I decided to make my own template with the basic structure settled.

Thanks to my friend Bernardo cant-wait-till-you-get -home-so-I-did-it Heynemann, we already got Windsor container up and running.

Next Post, working with ASP.MVC and overall feeling so far.

*NNF:Next, Next, Finish.

ASP.NET MVC Experiences

claudio.figueiredo — Thu, 26 Jun 2008 16:47:27 GMT

There´s sometime now there I´ve been wondering toying with the new ASP.NET MVC. I´ve been really impressed with what I´ve been hearing about it, and specially what I´ve been reading in Scott Guthrie´s blog, but only after the RC3 it got me really impressed.

So I decided to move my fat a$$ a little and do some constructive blogging for a change and create a series of introcdutories and eventually more advanced posts about my experinces with this new toy.

Stay tuned.

Interface Domains

claudio.figueiredo — Sun, 22 Jun 2008 08:04:51 GMT

It a long time since I've been having the idea that the User Interface is a Domain on it's own, and while reading Evan's DDD book it's only getting stronger.

First, when I stumbled on what he calls the Smart UI Anti-Pattern, I got a little disappointed. Not with him or the book, but with myself. Would I be too wrong on that?
Here I quote his words:

"Put all the business logic into the user interface. Chop the application into small functions and implement them as separate user interfaces, embedding the business rules into them. Use a relational database as a shared repository of the data. Use the most automated UI building and visual programming tools available [Evans p.77]."

But then I started realizing, this only applies when you're dealing with the U.I. as a layer to interact with your Domain, but not as a concept ubiquitously related to it.

Often always the U.I. is the main interaction that the user has with the software. He could interact indirectly with software in other ways, but it's when dealing with the User Interface that he perceives the most business value that he expects when interacting with the software development process. That's one thing that I was always sure about and one of the reasons that I think makes Agile close interactions so invaluable.

But the thing is: User Interfaces are a Domains on themselves.

And I mean Domain, as Evan's presents it.

Whenever a developer works with a Domain model; a clear, concise, business valued model. He deals with core business concepts. Concepts related with business experts experiences and their knowledge with the problem at hands, and transcribing these knowledge to Interactive Interfaces has to major concern points:

Even if a team captures the Domain in the most precise way, it's generally when translating it to the U.I. that that is the greatest diffusion between the concept and the implementation.
Grasping business concepts is hard. I had some projects in the past where interviewing business experts separately and together led to two completely different set of responses. But presenting the same people the U.I. (prototyping) led to a fairly greater number of different responses.

These two points make invaluable the abilities, of:

create/change the User Interface without affecting core domain concepts.
apply constraints in a way that do not defy business constraints and yet are business constraints on themselves.
present/relate Domain concepts as Entities, Value objects and aggregates without violating the concepts meaning.

Those are small but important points on establishing cohesion between design and implementation, specially on a Web environment, and that why that DDD concept comes to our help again.

In my point of view, the same concepts that's applicable to Business Domain Modeling are applicable to Interface Domain Modeling.

In a interface you can have:

Repositories, for retrieving and persisting Interface data.
Services, for complex operations between Interface elements.
Factories for creating Interface elements and components.
Even more advanced concepts as Anti Corruption Layers are applicable as well, when creating Facades for decoupling the use of legacy U.I. components.

Those examples above are specially true when working with R.I.A.

Well, as any developer does (or should ;p ) I've started coding these concepts and with that, a new Stormwind Project is on it's way and I hoping I'm blogging on it soon.

Stay tuned.

More on DDD and Self Improvement

claudio.figueiredo — Sat, 14 Jun 2008 02:56:44 GMT

Yesterday I talked on how Evans' book has been influencing my work, but it's usually on my pet projects and O/S initiatives like those on Stormwind. As a employee on a company that works with C.O.D.* methodology, I have little chance to apply it on usual work. Or at least I thought so.

I used to think that for you to use DDD you had to have you're whole application based on a Domain or it's was a futile initiative. Once again Eric's writings had me eyes opening.

Today I got a peculiar, as peculiar as most of what I do, task. Last week our largest application had experienced some unexpected circumstances whose were out of our control. Nevertheless those circumstances led to a side effect of it sending a 10k error message e-mail in a hour, crashing our customer corporation mail server.

Reasons apart I was settled with the job of first tracking the source of this odd behavior (it was not supposed to behave like that in the oddest of the scenarios) and then modify the error messaging layer to it stops sending multiples e-mails of the same type and source in a short period of time.

I don't agree with the reasons or the way of that, but it was the task assigned and some had to do it. Unfortunately it had come to my lap.

So I started what I do best. Code. But that time the code came a different way.

That's how it started:

First off, we sited and had defined what was a business 'Web Exception' and what identified it as unique on our context.

It was defined that a Unique Web Exception was an Exception triggered from a Page of a Type in a Defined Interval .

Without realizing it, I was defining my tiny Domain, and my first (and only) Entity.

And so the Code begun with the Model:

public class WebTriggeredException {
    
    public int Code { get; set; }
    public Type ExceptionType { get; set; }
    public DateTime? LastRaisedDate { get; set; }
    public string Page { get; set; }
}

Unconsciously I was defining my Domain and it's definitions.

Then came the Domain infrastructure in the form of a Service and Repository. But the thing was I not persisting it to a RDBMS. I was persisting it to Memory; Session to be more precise (not my decisions I should note). Without caring with the media it was persisted I was using the right patterns to the right job. Respecting the boundaries and concerns of my domain.

The fact was that in a hour and a half I had almost done with the task (the fun part at least) and the business logic resumed to:

public override void HandleWebException(Exception sourceEx, 
                        long applicationId, 
                        bool isDevelopment, 
                        string[] usersToReceive) {

    if (!WebTriggeredExceptionService.ExceptionWasRaisedInLast10Minutes(sourceEx)) {
        WebTriggeredExceptionService.RegisterException(sourceEx);
        base.HandleWebException(sourceEx, applicationId, isDevelopment, usersToReceive);
    }
}

Abstracting that I was almost writing a Facade to encapsulate an already existing logic, I managed to arrange it in a structure that applied most of the concepts that I've read in the past two weeks. And didn't notice that until it was done.

Can't stop saying that I'm please with myself, but what really pleases me is that I'm only halfway the book and if things keeps coming like that, I'll be a better programmer by the end of the month. lol

*Cost Driven Development

Unique Experiences

claudio.figueiredo — Fri, 13 Jun 2008 02:17:24 GMT

It's being two weeks that I've been reading Eric Evans DDD book, and it's been a pleasant time.

More or less at the same time I started a new Project (more on that later), and it was impressive how his writings has already influenced my work.

I've wiped out all my Domain code three times since I've started reading, more on less on the same time I ended each chapter.

In fact my Domain had not changed much, but the way the Entities related to each other having my aggregates boundaries clearer.

The same way I've embraced the Knowledge Crunching process, and every time I started rewriting it, more defined the interactions, behaviors, rules and scope became. More palpable too.

I've already read about DDD from other sources and had long talks with friends about it, but it's different experiencing reading the original work. The way Evan writes, with real circumstances and real issues, is a breath of fresh air after a very dry season. I've been feeling like a man who stood on the shadow under a tree looking to the sunset, but only now coming out to the sun.

A unique experience indeed.

Talking about Link

claudio.figueiredo — Thu, 08 May 2008 14:45:57 GMT

My friend Heynemann just sent me the most cool list of Linq fo AnyWhere.

The one´s I´m really interested in are:

LINQ over C# project
LINQ to NHibernate
LINQ to NCover
LINQ to Expressions

Hope it Helps.

Linq to NCover

claudio.figueiredo — Thu, 08 May 2008 01:31:38 GMT

Recently I've seeing some wicked stuff done with Linq, but this one is, to say the least, Outstanding.

Joe Feser released this Linq to NCover.

Doing stuff like:

CodeCoverage c = CodeCoverage.Load(file);

var retVal =from mod in c.Modules
            from cls in mod.Classes
            from method in cls.Methods
            where method.Name == ".ctor"
            select method;

Is, somewhat, surreal.

Bug of the Day

claudio.figueiredo — Fri, 15 Feb 2008 02:20:08 GMT

Something -a bug- happened today that made feel like weeping.

One of those nasty bugs that when you catch it, make's you scream like you have won a war.

I'm working on a Project that I was not involved on it's basic definition. And in cases like that some hidden stuff always pop out.

Based on a DDD approach this project has a module entirely delivered by Services, which are IoC'ed with Windsor on it's clients. So far no big deal.

But last night, our QA team was validation a particular routine which was giving lot of Developers headaches.

When I was presented to the the Bug I started digging on this project's foundation.

The maddening piece of code was something like that:

     foreach(ScheduledItem item in items) {

        IoC.resolve<IClass>().Do(item.stuff);

    }

The problem was that with every Iteration I received an error. Random.

Sometimes it was and PL/SQL error, sometime a null reference error, sometimes neither.

I got stuck with it for some hours.

Just when I thought that was closing on becoming crazier, my salvation came in form of another error.

    System.ArgumentException: An entry with the same key already exists.
  

Hell, how I loved watching this. Haven't been so happy in seeing and error message in sometime. At least, knowing some Internals of the .Do() method, I could elaborate on what was happening.

well, to make a long story short, my issue was that when adding the components on Windsor container, all services were being injected with a Binsor script adding all of then with:

    AddComponentWithLifestyle("Class", typeof(Class),IClass, LifestyleType.Singleton) ;
  

Dang. Every second time IoC.resolve<IClass>().Do(item.stuff) was called, with all-internal-fields-populated I got an error.

It turns out that that's the 'One Service' which has private fields outside the Service's Operation and those fields were never reset on the new method's call.
The error was random because the behavior of the method depend's on the item passed as parameter.

After that, I changed the LifeStyle to LifestyleType.Transient, which generates a new instance (no worries on performance here, it's an batch schedule operation) every call, and everything went fine.

I felt ok after that, but it was one of those moments when one thinks:
- "if I was involved from the beginning at least I would know where to look at".

Sad, but true.

When your foundation is good...

claudio.figueiredo — Fri, 15 Feb 2008 01:28:49 GMT

Just assembling my coding environment on my new-old (bought it from Heynemann, when he left to UK) computer.

Once again StormWind made my life easier.

Just download our code form svn repository, set up nant path and, Voilá:
- Everything's working just fine, thank you.

Every project, every test, fxcop, ndpend, Everything!

Our build configuration structure is so neat, that I need nothing more then two actions to have it working on a brand new environment.

Should blog about that someday.

StormWind and Enterprise Applications

claudio.figueiredo — Thu, 14 Feb 2008 03:59:39 GMT

I've reached a point in my life of great changes and as the smart person that I like to think I am, I concluded that it's time for some reconsideration.

Don't get me wrong. I've always had the habit of continuously reevaluate my actions and decisions, but it was mostly on the personal side of my life. Professionally it's no that so.

Not that I'm not aware of the needs of the path I choose as a professional, but precisely because the continuous improvement demanded for someone working on Application Development nowadays, make it's absolutely necessary that every time, every day, every minute you make that minute a moment of improvement on the total knowledge you have. So sometime's I thing that learning is enough as a professional refinement, but I've not agreeing with that lately.

What I mean by reconsideration is more of the career aspect of my professional life.

I always praised myself as a professional who've been through the whole application development lifecycle, and I still think that's true.

I've been a developer from most of my professional life (currently about 13 years), but as any life it was full of up's and down's and sometimes I was leaded to take some paths that I did not intended to.

Not that it's a bad thing, I'd like to learn every thing I can from any experience I have. Good or Bad.

I've been, Coding, design application,writing specification -some technical some non-technical-, testing, working on QA with UAT, managing projects from a political and non-political perspective. I've worked or been in touch of a vast set of technologies that made my think-outside-the-box way of being, feels like natural.
I even had my own startup for some three years, which made me consider things from a whole new point of view almost on daily basis.

But lately I've been questioning myself more and more often:
- Where it'll lead me to?

So I decided that to get this answer I'll take as a first step, and not a quick one, reevaluate my skills.

As a member, and co-founder of the StormWind Project, one of the things that I'm more proud to be part of, I'll start another project, one focused on being an Enterprise Application, witch I'll try Posting every step from it's conception to it's delivery and make a self analysis of my skill's and experiences in the specific area that I'll be working with, and the way I'll feel about it.

Keep tuned.

Heynemann @ TW

claudio.figueiredo — Thu, 14 Feb 2008 03:20:55 GMT

Mr B. Heynemann, ToughtWorker.

Dude, Gratz!

Developer level 71, and counting. :D

Hope you and your Lady, every luck in the world and that you keep rox'ing as always!

glhfgg!

My Friend is a ThoughtWorker

claudio.figueiredo — Mon, 12 Nov 2007 21:14:20 GMT

It's with great pleasure that I announce that our dear friend Heynemann just got hired by Thoughtworks.

Read more here.

I've been with him through most of the process being as supportive as I could and encouraging him the most I was capable of.

No need at all.

It only proves that we're right in hope, and sometimes it's all we got, that COMPETENCY PAYS OFF!

Even being a big responsibility, and one I think that he's fully up to, that's a path that I think that leads only one way: - Success.

Man, all my very best wishes that you keep doing as good as you ever had and get nothing but the best time of your life.

Your pal.
CF

Ayend 'Oren' Raien, a really weird guy...

claudio.figueiredo — Thu, 27 Sep 2007 02:52:02 GMT

Oren Eini, aka Ayend Rahien, is a really, really weird guy.

The Geniuses weird kind I think, but weird nevertheless.

Despite the fact that he writes at least 5 blog posts a day (almost all of them very insightfully), code amazing stuff, being Rhino Mocks one of them, he's also the kind that code just to prove that he's not drunk!

I've done much drunk coding in the past (not any longer that I'm a respectful married guy =} ), but never coded just to prove that I wasn't. lol

Twisted minds on I.T. field

claudio.figueiredo — Thu, 27 Sep 2007 01:37:38 GMT

Tonight I was laying in my bed with my wife, both of us reading. She was reading a data structures book and I was catching up on my daily feeds. For some it would be a strange scene, but I take it as a natural one when both of a couple works on I.T. field.

At some point I looked at the page she was reading and saw a ERD, and was a pretty simple one. Basic stuff indeed.

What really caught my attention was that the following relationship was show as an example of ERD:

Sometimes it strikes how odd enough we are without any help of this kind. lol

Happy Birthday...

claudio.figueiredo — Wed, 12 Sep 2007 02:52:31 GMT

... and all my wish of health, happiness and lots of money (lol !) to my Dear friend Bernardo Heynemann!!

Dude! It's one of the top things in the last years of my life meeting you and becoming your friend!

Binário FTW! :)

Stormwind Project FTW

claudio.figueiredo — Tue, 04 Sep 2007 18:04:36 GMT

It´s with great pleasure and honor that I announce that the Stormwind Project Community Portal was born today.

It´s a awesome feeling to be part of something that big and i´d like to give my Greatest THANK YOU to my Pal Heynemann for letting me give my humble contribution to this major effort.

Hope you guys and gals still keep tuned ´cause great things are on the way.

Meetings

claudio.figueiredo — Thu, 30 Aug 2007 23:42:48 GMT

First One:	09:00 - 14:00
Second:	14:00 - 17:00
Some yadayada...	17:00 - 17:30
Third:	17:30 - 18:30
REAL work---->	18:30 - 21:00

And Mr. Adrian still worries about the right Meeting...

MS Brainwasher

claudio.figueiredo — Thu, 30 Aug 2007 02:22:12 GMT

- In the Beginning there was The CGI.

(At least for me.)

Some times i get surprise by how the sum of our experiences changes us without noticing that a change even happened.
The change sometimes is so profound that one could swear that nothing had ever changed at all. That things are, and always were the way they are.
Some weeks ago i was faced with a singular problem (the kinds that make us want to jump through the window!). I had a Webform, with a DropDown list that was loaded after an event triggered in the form by a DatePicker-like control being both of then inside an UpdatePanel. So far so good.

Than came one user (I’m one of those 'blame the user' guy, I gotta admit it), and made the simplest of the requests:

"- I'd like to have the dropdown list loaded not when i change the date in the DatePicker, I’d like to have it changed only when i click the DDL. When my date change's, I’d like it only being cleared."

- Ok. I said. Nothing too difficult.

I though:

"Sure too easy. Just hookup the load method in the OnClick event of the DDL."

So it happens that i just realized, that there is no server-side OnClick in DDL.

"Ok.." - i thought - " just gotta add a client side onclick call to the DDL, and make it call the __doPostBack(). Easy."

Not really.

So it happens that Ajax.Net doesn't like being bypassed. The callback wasn't fired and i've got to trick it a little bit.
Ok, I’m used to trick Webform's. I've being doing it since Asp.Net 1.0, so it was no news.

After messing around for an uncomfortable few hours I’ve got it working.

Then, being Agile as i never was, I’ve called my user (oh, dear user!) t show him the job 'done'. He watched when i presented the new behavior and said:

“- Ok, that's it. Just one little problem. The DDL still need to be opened when the content reloads."

Ok then. It's not a trivial task since DOM doesn't give tools for that job, but i'm smarter than DOM.

First of all i recurred to own set of tools, being ExtJs and jQuery some of them. I already knew that Ext would do the Magic of expanding a DropDown for me, so I thought (you already know how I like thinking, don't you? =} ):

- "Yeah, right. Just gotta hook the reload event of the UpdatePanel to the ext.combobox.expand() method, and it'll be allright."

How fool am i? How fool for believing such an event exists. How fool for trusting M.S. (Mort Softwares) that everything woul do nicely working with GREAT Ajax.Net.

After that i had a really hard time. Trying to bind things with such heterogeneous frameworks as Ajax.Net and, huh, 'EVERYTHING ELSE' is not for the faint of the heart.
In the end i had given up trying to make then speak to each other and rebuilt the load method required by the DDL as an xml-spiting-handler and bound it to the ExtJs ComboBox, applied to a Webforms DDL, with it's native Ajax Calls and, after that, I’ll I needed to do was:

Combo.on('load',function(){
this.expand();
});
Ok, i had it! Just the behavior that my friendly user asked!!

Cool, everything was fine, ok?
- NOT!!!!!!!

No, it wasn't. And here let me starting explaining why I’m entitling this post as MS Brainwasher.
After struggling with tiers that i knew pretty well (being Ajax.Net the least known), and doing something that I’ve being doing for the last eight or nine years, that I’ve done with even Perl, I had a fight that I’m not so sure I had to endure, and definitely I didn't like it.

So to describe my feeling for all of it,’ I’ll tell how it ended.

When testing, everything was working smoothly, everything but getting the value of DDL.SelectValue. Nothing i did worked. Nothing.

Because it was almost midnight, because i was tired and hungry and because if looked one more time at that code i was throwing myself from my window, I decided to ask my dear friend Heynemann for a help, by wich he replied:

"Why don’t you get it's value by querystring?"

I felt stupid. More stupid then i felt in some time.

When bypassing the Webforms own methods to reload the DDL, he was not reflecting the change in a way that the webform was understanding, that i already knew, but not considering obtaining the value trough a simple Request.QueryString was too much for me.

That's it fellas. MS not being content writing tool for Morts want's us all turning into Morts as well.

Something, which they’ll never do with me! For sure!