Friday, 19 December 2014

Il tuo obiettivo per il nuovo anno? Entrare in Red Gate Software!

Guarda il video per scoprire cosa significa essere uno sviluppatore software in una delle migliori aziende software inglesi. Sono un italiano che 5 anni fa ha deciso di fare il grande passo e andare a lavorare in UK. Posso dire che e' stata una delle decisioni migliori della mia vita!

Vuoi lavorare con noi?
Per un accesso privilegiato, scrivi una mail all'indirizzo andrea.angella (at)

Friday, 12 December 2014

The pleasure of Down Tools Week

I have just arrived home.

It's Friday and an another Down Tools Week is ended.

I am writing this post to capture my feeling in this exact moment before my emotions disappear and I start to enter in the "Week End Mode".

I feel very tired. It was hard work but I am incredibly proud of what we achieved.

For the entire week, I didn't have meetingsI didn't check emails but I only focused on writing the minimum code that works in order to present something for the "Show & Tell" that usually happens on Friday afternoon.

The feeling during Down Tools Week is awesome.

Down Tools Week: feeling awesome
You are completely absorbed on the tasks at hand, in the most pragmatic way you collaborate and assign tasks between the newly formed team. You can feel a constant release of adrenaline. Even after work, you can't stop thinking about what you want and should do the following day.

The most intriguing thing is that even if I worked very hard and I ate very quickly just to be able to start coding and squeeze every minute, the time passed incredibly quickly. You don't feel the time at all, actually you fight against it.

This is what I define as "Fun", what I define as "Feeling a programmer" and what I define as "Feeling alive".

Surely my passion for programming amplifies these emotions.

Psychologists call this feeling "The Flow".
The FlowA mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement and enjoyment in the process of the activity.
I never worked with James and Peter before. Actually I never met them before in the company. In a week, I have learnt to work with them in a very effective way. I don't know if they feel the same way but I have to say that I am very impressed by what a team can do in a so short amount of time. It is fascinating to see what a bunch of people can do when time is given to them to do what they want.

The initiative is called Down Tools Week an integral and fundamental element of the culture of Red Gate where creativity is unleashed, people are empowered to learn together and create great things.

When I was young, I used to feel like this quite often. I coded games for my friends losing track of the time while I was doing it. This week remembered me those good days.

I'd like to thanks Red Gate to offer me the ability to feel in this way. I'd like to thanks James and Peter for helping me in developing further the idea of "Code Complexity as a service" (technical details will follow in a new post).

Above all, this week was seriously fun!

Monday, 27 October 2014

Webcast: Vuoi essere uno sviluppatore software in Red Gate (UK)?

Red Gate Ingeniously SimpleGiovedi' 13 Novembre 2014

evento online
Ora: 17:30 - 18:30
SpeakerAndrea Angella
Q/AJodie Pinkowski 

Red Gate Software produce "ingeniously simple tools" per professionisti e sviluppatori Microsoft in tutto il mondo. L'azienda e' principalmente specializzata in MS SQL Server, Cloud, .NET e Oracle con l'obiettivo di diventare leader nel Database Lifecycle Management (DLM), la componente database dell' Application Lifecycle Management (ALM). Sviluppatori e DBA saranno in grado di trattare database come ogni altra parte dell'applicazione adottando processi di sviluppo moderni, come continuous integration e continuous delivery, per rilasciare spesso e in modo sicuro.

Red Gate

Per raggiungere questo obiettivo ambizioso, Red Gate e' anche alla ricerca di sviluppatori software italiani.
  • Ti sei mai chiesto come possa essere l'esperienza di uno sviluppatore software in UK?
  • Sei alla ricerca di un ambiente di lavoro piu' stimolante e gratificante che possa veramente farti crescere professionalmente?
  • Sei alla ricerca di un migliore bilanciamento tra lavoro e vita privata?
  • Stai considerando la possibilita' di fare una esperienza all'estero?
Andrea Angella e' un italiano che lavora in UK da 5 anni e presentera' tutti i vantaggi di lavorare in Red Gate dando risposta a molte delle domande che un italiano si pone prima di compiere il grande passo. Durante l'intero webcast, la responsabile delle risorse umane, Jodie Pinkowski, sara' a disposizione per rispondere direttamente alle vostre domande (Only In English).

Friday, 25 July 2014

Database Unit Testing and Learning TSQL

Did you know that you can write database unit tests for SQL Server?

There is a framework called tSQLt that helps you to do it.

There is also a tool from Red Gate Software called SQL Test that provide a nice UI on top of it, integrated in SQL Server Management Studio.

What about using tests for learning TSQL?

I think that it is not unreasonable to design a TSQL course where each lesson is made of a set of tests that you need to make pass. This idea of learning by making tests pass is used in the nand2tetris course that I am doing with the friends of the Cambridge Programmer's Study Group.

In this post, I try to create an example using tSQLt.

The database I use is from the Training Kit: Querying Microsoft SQL Server 2012.

Installing tSQLt

First run the following SQL statements.

Execute the tSQLt.class.sql script provided by tSQLt.

Creating the test

First, you need to create a test class that we call Tests.

Then, we create a test.
The framework tSQLt allows you to create fake tables but in this case the test use the actual table HR.Employees and the actual data contained in it.

Running the test

You can run the test individually using the tSQLt.Run or alternatively you can run all the tests in the database using tSQLt.RunAll
You can also create a keyboard shortcut to run all the tests easily.

You can see that the test fail!

Make the test pass and learn

You can make the test pass simply adding the DISTINCT keyword in the select statement.  

Run the tests and they all pass.

I really like the idea of learning by making tests pass.

What do you think?

Monday, 7 July 2014

Enneagram Personality Test

I like psychological tests to learn more about myself.

Few months ago, I tried the Personality Type Indicator test.

Today, I did the Enneagram Personality Test that shows how you are balanced between nine personality types (called wings) and to see which one are the dominants.

It looks like I am pretty balanced with a preference of the Type 3 (The Achiever), Type 9 (The Peacemaker) and Type 1 (The Reformer).

What is your result?

Thursday, 5 June 2014

Secrets of Success from the Story of Bill Gates - Part 2


Never give up there is always a way out. Do what you are supposed to do; it will lead to bigger opportunities along the way.

If you can make up your mind that you will not settle for less, you will not settle for less. You will keep right on going and you will achieve your goals and dreams. If you convince yourself nothing is impossible, nothing will be impossible for you.

Don't concentrate on how hard it is but focus on the reward and satisfaction you get by achieving your goals.

Always focus on the final outcome from the start, never lose that ability to focus. As the road gets harder, you get harder; as the road gets tougher, you get tougher; as the journey becomes difficult and seems like it’s impossible, just continue to focus and keep going and watch what will happen. The only true failure is when you give up and you stop moving on.

Reward your progress when you reach a milestone.

Bring your best to every situation; you may never know when your breakthrough opportunity presents it to you. Persistence always pays off. Don't take rejections to heart or personally, it’s only a normal process of taking out what is not good for you. Persistence takes action.

The most successful people in life are always persistent. Persistent people are often accused of being cold and heartless, but a careful re-evaluation shows this is not the case at all, they are simply singled minded in their pursuit of their own personal destiny.

Wednesday, 4 June 2014

Secrets of Success from the Story of Bill Gates - Part 1

This is an very inspiring and motivational book: Secrets of Success from the Story of Bill Gates.

Bill Gates is a person that always inspired me and continue to inspired me. 

Bill Gates built Microsoft from scratch – he created the single most influential technology company of our modern age, and it made him so wealthy that he is now able to focus on the eradication of poverty and disease through the work of his charity foundation.

In 1994, Gates and his wife Melinda founded a charitable organisation called the Bill and Melinda Gates Foundation which supports initiatives in global health and education. The aim of the foundation is to eradicate poverty, disease and illiteracy from the world.

Bill Gates has received numerous international and national accolades, and honorary doctorates from the Royal Institute of Technology, Stockholm, Sweden in 2002, Waseda University, Tokyo, Japan in 2005, Harvard University in June 2007, and other universities. He was also made an honorary Knight Commander of the Order of the British Empire (KBE) from Queen Elizabeth II in 2005.

The book describes the key elements of  the history of the Bill Gates but he also introduce a lot of examples from other great people who are equally inspiring.

Tuesday, 3 June 2014

Learnings from software development coaching sessions

Back in November 2013 I wrote a post sharing with you my decision of being mentored by a friend and agile coach Matteo Baglini with the goal of exposing myself to agile engineering practises and become a better developer.

At the time, I promised to write posts about my learning but ultimately I didn't. So, it is time to start now!

First of all, I wish to thanks my manager Dom Smith in Red Gate Software to offer me the opportunity to have these sessions during working hours. This really offers me the ability to have sessions regularly every week.

In this post I will condensate the learning of the last few months of mentoring with links to the various resources that I read since then.

We started discussing TDD and the approach described by Kent beck:
  1. Write new code only if an automated test has failed
  2. Remove duplications
Duplication is the most important code smell and it can be hard to see. For this reason, sometimes it is useful to write verbose code just to help you find duplications.

I did the full Money example in the book TDD By Example exactly how Kent did it (with few changes as I did in C#) and deeply reflected on each step. I spent a full day to do it but it was worth the effort.

Learning well a refactoring tool like ReSharper is very important. However it is important to consider that the biggest advantages of a refactoring tool is not merely productivity:
  • Avoid the human error
  • Remove the context switch between using keyboard and mouse
  • Shorten the feedback loop by decreasing the time needed to refactor a piece of code
  • You can answer quickly questions like: Is the new design better?
Doing a kata multiple times without changing the solution to just focus in how you code and use refactoring tools is a very useful technique.

Here is a collection of very useful advices:

  • Check the error message when a test fail
  • Run tests often
  • After a refactoring run the tests
  • Avoid copy & paste as much as possible
  • When you find something to do, don't stop your current task. Add a note and do it later.
  • Don't stop the flow only to rename a method or a property! Add a note and do it later.
  • Primitive obsession can be often removed by introducing Value Objects
  • Sometimes you can add a test and comment it out in order to do necessary refactoring
  • Don't be too confident! Always use tests to validate what you are doing
  • Keep tests as stupid as possible. Limit test logic as much as possible!
  • In case of regression (red bar) never change test logic otherwise you won't know what was right
  • If you lose control, just slow down or discard changes and restart
  • Don't restrict yourself in a Top Down or Button up approach.
  • The code guides you. TDD is a feedback tool.
  • Consider adding code even if it is not strictly required to improve readability or simply to add symmetry
  • Some tests are simply tests to support you during development. You can remove them when other tests cover the same functionalities. Don't be afraid. 
  • Consider the "Copy Type" ReSharper command
  • The production code tests the tests!
  • Extract Method is a powerful refactoring tool
  • It is sometimes useful to make a private internal method public just for the sake of temporary writing unit tests but don't submit that code! Use it only to increase your knowledge about the problem.
  • Learn how to do small steps when needed.
  • A test is done only when duplication is eliminated!
  • Consider writing a test to force the creation of an object that we expect to need late but attention of not doing upfront design
  • Relying on the compiler can be a useful technique
  • If it takes a lot of time to make a test green... reflect!
  • Prefer static methods to factory classes when implementing the factory pattern
  • Getters are smells. Pay attention to not use objects as mere data structure.
  • Resist the temptation of not creating new classes... try, get feedback and see!
  • Observe the frequency of change. Change should be distributed among classes.
  • Use the Single Responsibility Principle to see pattern of change
  • The class who own the data should do the operation: Tell, Don't Ask!
  • In designing API it is best to offer a single way to do something. Make it simple!
  • Use the history in SCM to get insight about your project
  • Analyse temporal correlation of class changes
  • If you feel that something is annoying in the code base that is a sign of poor design.
  • Remain at the same level of abstraction within a test
  • Write a high level test and when you see the need to cover a lot of cases go down of one level of abstraction and write more specific unit tests.
  • You will often be pushing tests up and down between different levels of abstraction
  • Remember to not look inside the object when you do testing even on individual classes! Test the behaviour so that you can easily change the instance of the class with a new class but keep the tests intact.
  • Do not use TDD as a way to get permissions to write production code (that is cheating).
  • Do not be too enthusiastic about new technologies or methodologies. Slow down and reflect. There will be always a hype and later a fall. If you are pragmatic you can fall less.
  • Consider writing the assertion first

The essence of object orientation is thinking about behaviours

TDD test are always behavioural and at different level of abstraction. TDD can be done at different levels of zoom: it is sort of a dance between them. Unfortunately TDD has been often misunderstood and even attempts were made to fix this with ATDD and BDD. But these methods have often been identified with tools and things like Cucumber only create a new layer without bringing much value: having the on-site customer is far better than executable requirements that are a dream.

Pair programming helps a lot to keep focused and the role of navigators is supporting drivers in maintaining discipline and avoiding distractions

I and my mentor discussed many times about the Theory of Constraints and the importance of identifying bottlenecks in order to remove them. It is quite interesting to note that also humans can be a bottleneck and therefore an issue that can be addressed by increasing sharing. This can be done both with pair programming or with the Expert in Earshot pattern.

I never known exactly how to achieve high cohesion and loose coupling regularly until I started writing isolated tests, Kent Beck
I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong. Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we’ll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order. Kent Beck