I will discuss about my generic approach in refactoring in a specific post, but a few weeks ago I found an old code and I remembered what was happened that specific time.
Like in every nightmare, everything started with a simple request
“Could we re-arrange few lists of categories in a different layout?”
More in detail, the task was to rearrange in a different rows-columns layout four lists of categories sorted and grouped by macro category.
In theory pretty easy so the answer was “of course!”
Let me set the scene
…at the end the Great day came, you would have had to go live in a couple of hours and the tension and the excitement were tangible. Then…something went wrong. Badly. What happened after it is not so easy to recall, the servers stopped to work and some people started to shout orders, other people started to type on the keyboard frantically or talk at the phone, someone was reporting about an accident in the server’s room, something maybe went on fire.
You were in the room, paralyzed, with the corner of your eye you were sure that someone was climbing over the window and someone else was ready to set himself on fire in the middle of the room before the End.
A terrible silence came upon the room and everyone in the room looked at that Guy.
The Guy slowly bent over one desk and pointing at the screen said
«It’s me…or there is missing a bit of padding in that label?»
What’s happened next? Well… Continue reading
“Keep it simple” is a good advice, but sometimes it is not so easy even in projects very small.
Just for fun I have tried to recreate a Memory game in AngularJs.
As a kind of game it is not a complicated one, but it was interesting for me to evaluate the time needed in coding using the framework.
The memory game is quite famous among kids, but it is enjoyable even for the adult persons (http://en.wikipedia.org/wiki/Concentration_%28game%29). Continue reading
I hate the metrics.
Really, I hate them.
Generally speaking now I hate any file excel in which I should put a lot of numbers.
Because years ago the 99% of the time that I took that metrics I didn’t know what to do with that numbers, I didn’t know when to use it, I didn’t know how to read it in order to be useful.
In my past experiences the metrics that I had taken were never useful to improve a workflow or avoid the same mistake.
Gathering those metrics had been only a colossal loss of time.
On the server side is absolutely normal to decorate your Controllers or Actions with the Authorization attribute in order to manage correctly permissions and access to the resources/routes.
Sometime the problem is to manage the permissions or the roles in a much more atomic way in the views.
The scenario that a friend described to me was: I want in the a page to show/hide or enable/disable parts of the it depending on the roles of the user.
Prologue (suggested theme music for this post here)
At the end of June I moved to begin a secondment for one year in our London office. One of the purpose of the secondment is to help to implement a software developed by my team in Turin.
So I temporarily dropped my Scrum Master role and I became Tech Leader of a new project in UK that had to use the new software: we went live at the end of July, but a lot of things happened even if the launch has been a success.
The skills are the last big component in the Pawns and Tiles game: a skill determinates a possible action of a pawn and in some way defines its role on the board.
Every pawn has a set of skills, two of them are common among pawns, “move” and “combat”.
Move from a logic point of view is not a skill, but for the application’s point of view is managed like any other skill.
Combat represents the possibility to attack an adjacent pawn.
Basically every pawn can move and make a standard melee attack. Continue reading
User Stories are very central in any Agile methodology and very often are the first cause of a failure (or success) in a software development.
Speaking about User Stories with a colleague in London, I noticed like the topic is every time (no matter the Country nor the person) much more complicated than expected, mostly if you are new on the field.
If you speak about User Stories is quite simple that, at the question “How a User Story should be?”, your answer will probably be an emphatic “INVEST!”
I agree, but I’ve noticed that to apply the INVEST approach is much more hard than expected. The theory is pretty clear, but somehow not so much clear how to put it in a User Story.