BDD Spec Public Repository -- is it possible?

Looking back to my BDD experience, I remember that once we did massive refactoring (actually, it was rewrite process) having only BDD specs on hands (it was routing subsystem with access rights subsystem taken into account).

As the result we were able to rewrite 'from scratch' functionality with those specs with now problems.

Now I see that this experience can be spread to the most of well-developed problem areas: we can describe the most functionality via BDD specs, and share them.

Having such specs on hand, it is possible to write own implementation on different languages.

I will think this idea over :)

Голубятня: Чудо Compreno - Компьютерра-Онлайн

Голубятня: Чудо Compreno - Компьютерра-Онлайн

Job applicants and archiectural skills

This time we are hiring. The skillset is quite simple: problem-solving, architecture, c# and some client side javascripting.

You know what?

One of four developers Is problem-solving type and can describe a solution for given task from scratch (last time i've asked to provide sample plugin architecture for .net windows forms).

But I still believe that my next candidate will be ok :)

I know that some interviewers concentrate on c#/javascript language knowledge.

Some interviewers prefer to test architecturing and problem solving skills barelly touching language related issues.

I prefer to follow the last approach because often i see developers who do really know language syntax but their code was awful: lack of abstractions, pure testability, and almost all s.o.l.i.d. principles are not taken into account.

Today a couple of my collegues and me conducted an interview with a candidate. He has more than 3 years in development and seems quite smart, but has lack of architecturing and problem solving skills.

So my answer on question 'are we going to hire him?' was 'no'.

Hope next candidate on friday will be much better (looking at his cv i can hope)

Test-Driven JavaScript Development

I was suggested to have a look at this book:

Test-Driven Javascript Development by Christian Johansen

I revised it.

I believe that this book is worth to read, especially by developers who has a deal with  tons of javascript code on daily basis.

Description:

For JavaScript developers working on increasingly large and complex projects, effective automated testing is crucial to success. Test-Driven JavaScript Development is a complete, best-practice guide to agile JavaScript testing and quality assurance with the test-driven development (TDD) methodology. Leading agile JavaScript developer Christian Johansen covers all aspects of applying state-of-the-art automated testing in JavaScript environments, walking readers through the entire development lifecycle, from project launch to application deployment, and beyond.

Using real-life examples driven by unit tests, Johansen shows how to use TDD to gain greater confidence in your code base, so you can fearlessly refactor and build more robust, maintainable, and reliable JavaScript code at lower cost. Throughout, he addresses crucial issues ranging from code design to performance optimization, offering realistic solutions for developers, QA specialists, and testers.

Found a good presentation about Primitive Obsession antipattern

Good for beginners :)

Digging into the Git domain

Most of the time when you use Git it's enough to have a raw domain in the mind.

Branch, checkout, create branch, commit, push -- operations which can be easily learned and applied in everyday life.

But sometimes it's necessary to dig into details.

Last few days I was working on Git plugin development for our Target Process product, and now it's obvious that my knowledge was not so good to handle NGit API (the port of JGit).

First it's necessary to understand the Git domain.

I started with deep revising of Git manual to sort out all entities which Git operates with.

Here is my first domain diagram :)

By looking at this diagram it's quite easily to understand how root entities related to each other.

distributed architectures - importance of self-diagnosis and self-fixing

While implementing my first ESB architecture we've faced many environment configuration issues which was spotted by our customer support team.

Now I think that every environment-sensible application should meet several conditions:

1. It should be self-diagnostic. It means that in case if an application failed to start it is necessary to provide the full list of causes to user -- via log or other ways.
2. Application should be able to fix all misconfiguration cases.

We'll start to implement it here, then I'll post the results :)

Location:vulica Šaranhoviča,Minsk,Belarus