Status or state after all?

Which of them do you use and when?

This is what I've decided for myself:

"State" - is a set of attributes that define object's behavior and have a state machine of transitions. 

"Status" - is an attribute that holds a single character value.

Other options, suggested by my colleagues:

• use unthinkingly;
• use only one of them. always;

That's it, good luck!

A business to IT people collaboration tool announcement.

Something tells me that people occasionally landing this page are not so far from software development as my grandma is. 


Thus, I suspect, some of you guys out there might find my new endeavour useful.
We've developed a tool to help collaborate on requirements and usecases, trace them and estimate project efforts. 
A tool I desperately needed at my fulltime job before. 


Starting is simple, either someone adds you as a collaborator of his project and you get an email with a signup link, or you visit our awesome site and signup for our services yourself.

Nothing could have been easier. You will receive a welcome email and can now start working. Anyone can create a project and become its self perpetuating Creator. 

After you've created a project, you are welcome to invite more people to collaborate. When adding people to your project you have to assign them roles. There are three roles except for your exclusive one, namely: Project Owner - usually a business person in charge for requirements; Contributor - any one allowed to contribute to project's items, a Project Manager or Business Analyst; Viewer - a person, whose sole need is to read and observe activities boiling in a project.

So you've created a project and invited your colleagues to collaborate with you. Then you start by creating requirements, functional and nonfunctional. You define a release, you declare it to be mandatory and, say if you know what Kano is, you declare it as a Must have.

You categorize your requirement with tags. Though we provide a powerful set of tools to search through requirements, to sort and filter by literally every attribute, it is always useful to have a short sticker on an item to filter fast.  Filter by releases is in place, of course, for you to laser focus on what's vital for you now.

After you've created a requirement, your colleague takes up and traces it with a number of use cases that define works to be done to achieve required function. He also defines how complex a use case is and who is the actor to participate in it.

And now it comes to the most interesting moment, my favorite - discussion. You've required something no one knows how to accomplish. What can they do? Comment on your requirement or usecase!

Ok, everything is fine. You've managed to figure things out during your long discussion, and now you are ready to estimate how long it will take to develop a project you require.

Wow, it turns out that it is a rather simple task to find an answer.
The last thing to do is specify some details required to tune estimation calculation and you're through with it.

So it goes. 


I want to remind you that we are still in early stage, and there are plenty of things we have to improve. We need your feedback in order to make our service the bestest =).


Good luck!

How do you tell a good code?

Agreed with Ayende:
"... most good code bases are actually fairly boring. That is pretty much the definition of a good codebase..."


Source.


Good luck!

Speed up rails3 rspec2

If you've eventually fell asleep while waiting for your test suits to run, here's a good description on how to speed it up.


PS One little nitpick: all of the spork commands should be executed in bundle exec context as long we use bundler insted of rubygems.


Good luck!

Calculate LOC with one line of code

Found a very useful tip on how to quickly estimate the size of a project with only one line of powershell script.
Navigate to the root directory of your project and in powershell type the following:
(dir -include *.cs,*.xaml -recurse | select-string .).Count


Thats it. 
Good luck!

Execute Caliburn coroutine in action pipeline without UI trigger

Seems rather easy, isn't it?

Just put it into Presenter's Execute method and the did is done. Well, should it be like that I wouldn't wake up in the night and write this stuff!
Let's see what's there in Execute:

So, it just packs every single coroutine it has in SequentialResult and execute 'em. No filters pipeline used, no routedMessage. None of your neat filters applied to these coroutines.

You might ask what is the difference with executing coroutines as a result of some UI action, be it a routed event or a command. The answer is in the Caliburn.PresentationFramework.Actions namespace.
To be prrecise it is an Action Execute overloaded method that in simple case of SynchronousAction does the following:

namely calls preprocessor filters, delegates a call to method that might be returning coroutine, handles errors with rescue filters, calls postprocessor filters. That is a filter pipeline I am talking about.
Well, seems that Caliburn has everything I need. And all I have to do is just use it.

As header states there is no UI trigger, i.e. I want to execute a coroutine when nobody clicked a button, but rather on some external trigger. As an example, consider model update with call to any data storage during Presenter initialization stage.

Enter DegenerateMessage. This intellectual piece of code is a data container that is being handed to participants on courutine call pipeline in order to hint what was the original method name called.

Another intellectual piece of code is DegenerateMessageTrigger. It is so damn smart that it knows that in order to trigger an action it has to pass a message to message handler!

And yet another piece is a DegenerateMessageHandler. It really shouldn't be called that way as it performs really complicated things. Namely, it creates an ActionHost and when Process is called converts DegenerateMessage to an ActionMessage and put it into the standard Caliburn action pipeline.

If it seems like dancing on your head, then know that you are not alone. But wait, there is another part I forgot to mention. It is a simple interface IResultExecutor aimed to hide all that smart code under two methods accepting Expressions with lambdas calling methods that return coroutines.

Oh, and there is yet another thing. With Caliburn Micro you can accomplish the same with only one line of code.

Cheers!

The best explanation to ESB ever.

I've finally managed to reread some of old Udi's articles and suddenly realized that following few lines are the best explanation of what ESB is all about, ever.

I never want to miss it again that is why I repost it right here in my blog.

"it’s all in the message. Forget about remote method invocations and pub-subbing events—down on the wire it’s all just messages. The trick is to think of your system as passing messages at the application level as well.

Asynchronous message passing over queues. It’s really quite simple.

Once you’ve packaged everything into the message, that message can be dynamically routed anywhere, and so can its responses. The application doesn’t need to bind against any specific endpoint—it just drops a message addressed to some logical location. Infrastructure can make sure that messages get to the logical recipient, even if they change physical locations.

That infrastructure is what brings about the “Bus” architectural style between your distributed components."

As Udi says, you have to reread it several dozens of times, until it strikes to you.

Good luck!