Introducing Fluxo a Kanban dashboard for Trello Boards

Fluxo or Hugo Häggmark is not affiliated, associated, authorized, endorsed by or in any way officially connected to Trello, Inc. (www.trello.com).

Last week I introduced my latest “commute from and to work” project called TrellBan here.

So I received a very kind but to the point email from the Trello support team last night telling me that the name TrellBan was to close to Trello.

A bit surprised but at the same time somewhat flattered I began the hard work to come up with a really great new name for this open source project.

Fluxo means flow in portuguese (my mother tongue) and I think it is a short and easy enough name to remember.

So TrellBan is disontinued as of now and the replacement Fluxo is still an open source project that you can find here:

https://github.com/hugohaggmark/Fluxo

The latest release of the Fluxo can be found here:

http://fluxo.herokuapp.com/

And a demo of Fluxo can be found here:

http://fluxo.herokuapp.com/demo/

Sorry for any inconvenience this has caused,

Hugo

Fluxo a Kanban Dashboard for Trello Boards

Fluxo or Hugo Häggmark is not affiliated, associated, authorized, endorsed by or in any way officially connected to Trello, Inc. (www.trello.com).

Read this post for more information.

Fluxo
Fluxo

I’ve a lot of time between home and work every day because I live about 30 km from Stockholm in a suburb called Vallentuna.

That gives me about 1 hour of commute every day where I can sit with my laptop and hack stuff without disturbing anyone else.

I’ve been doing this for 1½ year since I’ve paused my usual “coach” consultant role and gone back to being a simple “web developer”.
Of course as I’m often the senior web developer in a team 🙂 I tend to do some coaching anyway but not the type of coaching I used to do that is coaching entire teams.

OK, so since the end of November 2014 our team at Fritidsresor (TUI Nordic) has been doing this new cool thing called Mob Programming.
That deserves a completely other blog post that I might write someday. (ooooh a cliffhanger)

Mob programming and the fact that one of our team members was going to work remotely made us switch from a physical Kanban board to Trello.
Trello is really simple and nice but has one small drawback it doesn’t come with any Kanban statistics in the box.

Our team coach did a lot of research in this area and didn’t found any good free plugins for visualizing Kanban statistics from Trello.
He did find Screenful (http://www.screenful.me/screenful-for-trello/) which is awesome but unfourtunately it isn’t free.

So I got the idea to make this my new “while I’m commuting from and to work” project.

The project is called Fluxo TrellBan and is completely open source, you can find the source code at https://github.com/hugohaggmark/Fluxo https://github.com/hugohaggmark/TrellBan/ and
the lastest working release of TrellBan can be found at http://fluxo.herokuapp.com/ http://trellban.herokuapp.com/.

If you want to get at glimpse of what the dashboard actually looks like (with dummy data) you can see a demo at http://fluxo.herokuapp.com/demo/ http://trellban.herokuapp.com/demo/.

I hope you enjoy Fluxo TrellBan,

Hugo

Stop doing TDD and start doing BDD with SharePoint!

I’m certainly one of those guys that like to do TDD and If you ask people what differentiates me from other developers you will almost certainly get the answer that I’m really serious about quality.  

But after my last project I’ve been become “wiser” or more careful with what kind of tests to use when and where. So why the unusually provoking title?

Last week I got a tweet from my friend Johan about tips on how to do TDD in SharePoint with assemblies that reside in the GAC.Stop doing TDD and start doing BDD with SharePoint

For a brief second I thought that I would just give him a list with the different methods/hacks/workarounds I’ve seen and then I thought:

“you’re only fighting the symptoms, we deserve better”

SharePoint lacks good mockable Interfaces and serves you with lots of sealed classes and static classes. That’s not a great foundation for TDD.

Furthermore we have the whole GAC thingy, also not a great foundation for TDD. If only I would have received a euro for every time someone in my last project asked me why the tests were not passing and whereby I asked “do you have an older assembly in the GAC?”

I can’t see how trying to do TDD in SharePoint will lead to anything but workarounds or hacks to get it working.

Another aspect of truly doing TDD is that you really need a vast knowledge of the domain and IMHO very few developers doing SharePoint development have the necessary knowledge.

In fact I did a test with two groups in my last SharePoint project. Both groups were told to TDD a small Document Set feature. Both groups were given 1½ hour. I coached the second team and 5 min into the exercise I told my group that let’s skip TDD and just do the feature.

The result was spectacular as you might have guessed. The first group almost didn’t make any progress at all and the second group didn’t come very far either. Why? Not enough knowledge of the domain and no mockable interface makes it almost impossible to do TDD in my opinion.

Still not convinced? Well it’s a free world go ahead, try it, fail and become wiser yourself.

I’ll even give you some methods I’ve used/seen/hacked/worked around the last couple of years (without any specific order of importance):

  1. Set Assembly version to 1.0.0.*, this way you won’t have any issues with the GAC thingy. But you’ll have lots of other side effects that you need to mitigate/automate.
  2. Retract dll’s in test setup/teardown.
  3. Write you class under test in the test project and then move it. Johan wrote about a great spin-off on this method here.
  4. Wrap SharePoint artifacts with your own Interfaces.
  5. Separate your domain from the infrastructure, and TDD the domain object only leave the infrastructure alone!
  6. Use a mocking technology like Fakes/Shims/Moles/TypeMock. This demands a really deep knowledge and understanding of SharePoint so if you think this is something you’d like to try, I say beware you’re treading in deep dark waters.

What you should do instead is to treat SharePoint as the framework it is much like the way you would treat the .Net Framework.

BDD is a nice way to do this, you invest more time in designing behaviors or capabilities of your application using SharePoint as one of those capabilities.

But that’s just my very personal 2  cents,

Hugo