Tuesday, November 6, 2012

Helping to spread useful techniques

That's interesting thing: it's almost 5 months as I don't have any projects here, at my workplace.

Firstly there seemed to be a position on new project, but then it was decided not to introduce me.

It allowed me to apply my skills on codebase analysis but then I became available for another projects again.

So I decided to help out my company and proposed the following topics for training sessions I can teach:

Behavior-Driven Development in action
  • Discover next evolutionary step in TDD – Behavior-Driven Development (BDD). In this training you’ll know how not to miss any of customer’s requirements and transform them into a form of executable specifications, which can be used for collaboration purposes between customers, QA and developers.
Test Driven Development in action
  • this training is dedicated to the Test-Driven Development technique. How to not to spend much time on debugging? How to design convenient-in-use API for your class structure?
This live coding session will answer two main questions: WHY every developer should be at least familiar with this technique and HOW it can be implemented in real code. NUnit will be used as a unit-testing framework.
Mock Object Frameworks in unit testing: how to use and when
  • Those who familiar with TDD &pamp; BDD would like know how to practice it more efficiently: This live coding session will demonstrate how to test pieces of code in isolation of the rest code with using of mock object frameworks.
Event-Driven Architecture (EDA): Overview
  • The training introduces in event-driven architecture principles. Contemporary world is event-driven, so often our software can be implemented using event-driven architecture principles in the most efficient way.
When EDA can be applied? What considerations can be taken into account and how actually it can be implemented with using of real EDA framework – that questions will be answered here. NServiceBus EDA framework will be used for demonstration.
Introduction to UML
  • Unified Modeling Language (UML) is a common language which is used for communication purposes among professional developers. How to share architecture? How to describe static structure or dynamic aspects – this presentation is all about it.

It's been a week as I am doing them.

It's interesting thing, but most people are interested in TDD. I supposed that it would not be so popular, but for now I have given two TDD sessions and one Mock Object Frameworks session.

Now I think that I will be spending my next couple of months (before I move to the USA) on that sessions, and I like it :)

P.S. I asked Vladzimir Tihon, the lead of .Net Lab here, at EPAM, whether his students need CRC card session, and he agreed that it would be nice.

I think that I need to prepare for it as well :)

Any more topics are welcome!

Thursday, July 5, 2012

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 :)

Wednesday, February 22, 2012

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)

Friday, February 17, 2012

Test-Driven JavaScript Development


I was suggested to have a look at this book:



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.

Saturday, November 5, 2011

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.